This makefile is based on makefile.vcwin32, but includes Neon
intrinsic optimization.
Co-authored-by: Gabor Kertesz <gabor.kertesz@linaro.org>
Co-authored-by: Cosmin Truta <ctruta@gmail.com>
Signed-off-by: Cosmin Truta <ctruta@gmail.com>
Fixes#398
It adds win-arm64 as an arm64 platform, by using a define which
is set to 1 for compilations that target 64-bit ARM processors,
otherwise undefined.
The ld version script should not be generated on Android.
Co-authored-by: Volker Krause <vkrause@kde.org>
Co-authored-by: Cosmin Truta <ctruta@gmail.com>
Signed-off-by: Cosmin Truta <ctruta@gmail.com>
The issue is that, by default, Git for Windows checks out text files
with CRLF line endings. This is a problem for awk, which is expecting
Unix-style LF line endings. When cloning on Windows and attempting to
compile on WSL, Mingw or Cygwin, there may be an error from awk.
The fix is to leverage CMake's ability to configure a file and perform
EOL conversions. We copy the awk scripts from the source directory to
the build directory. This portable method ensures they have LF endings,
and the build logic is updated to use the build directory version.
Intentionally avoiding .gitattributes to avoid setting precedent.
Co-authored-by: Christopher Sean Morrison <brlcad@gmail.com>
Co-authored-by: Cosmin Truta <ctruta@gmail.com>
Signed-off-by: Cosmin Truta <ctruta@gmail.com>
Generated files depend on other generated files, and this previously
resulted in the same custom command output being a dependency of
multiple other custom commands without a shared custom targets.
Adds a top-level target for each generated file and ensures that
commands that depend on generated files also depend on the corresponding
custom targets.
Per CMake documentation:
> Do not list the output in more than one independent target
> that may build in parallel or the two instances of the rule
> may conflict (instead use add_custom_target to drive the command
> and make the other targets depend on that one).
Signed-off-by: Cosmin Truta <ctruta@gmail.com>
Apply the following changes:
* Add FreeBSD (besides Linux and Mac) to the Travis CI testing.
* Use cc instead of clang for Xcode in the Travis CI testing.
* Upgrade the Windows test image from Visual Studio 2019 to
Visual Studio 2022 for AppVeyor CI.
Apply the following changes:
* Set CI_CMAKE_GENERATOR to "Ninja" by default in ci_cmake.sh.
* Set CI_CC to cc by default in ci_autotools.sh.
* Rename CI_SYSNAME to CI_SYSTEM_NAME; add CI_MACHINE_NAME.
* Apply other minor changes and fixes.
Implement the following updates:
* Add CI_SYSNAME and set it to `uname -s`.
* Set the default CI_CC value to "clang" on all BSD systems.
* Replace CI_SRCDIR_REL_BUILDDIR and CI_INSTALLDIR_REL_BUILDDIR
with CI_SRCDIR_NATIVE and CI_INSTALLDIR_NATIVE.
The former variables were hard-coded and error-prone; the new
variables are computed and safe to use.
The second call to write_eXIf doesn't check whether the first call
succeeded; no other chunks except tIME and the text chunks seem to be
doubled like this.
The second call causes the eXIf chunk to incorrectly be written twice.
pngimage.c:
Initialize sig_bits on a NOTREACHED path to avoid warnings about using
uninitialized variables.
pngstest.c:
Enlarge buffers and fix signedness to avoid legitimate warnings about
potential buffer overflows.
pngunknown.c:
pngvalid.c:
Use NULL instead of 0 for pointers and apply other style fixes.
makepng.c:
tarith.c:
Apply various style fixes.
Also remove the "last changed" version info from source comments.
The version control system maintains this information automatically.
The Unix paths in Bash do not mix well with the Windows paths in CMake.
The uppercase and the lowercase environment variables do not mix well
in MSBuild. Et cetera.
On AppVeyor CI, verification of Windows builds with the Visual Studio
toolchain used to work, perhaps due to one or more lucky coincidences,
but it stopped working after an upgrade on the AppVeyor CI site.
Update ci_cmake.sh as follows:
* Use POSIX commands like "mkdir" and "rm" instead of CMake commands
like "make_directory" and "remove_directory".
* Avoid using absolute paths in the CMake command line; use relative
paths that are accessible from both Bash and Windows.
* Clean up incidental mixtures of Windows and Bash-on-Windows
environment variables like {$TEMP,$Temp,$temp} and {$TMP,$Tmp,$tmp}.
For ci_autotools.sh, customize CPP, CPPFLAGS, AR, RANLIB, LD, LDFLAGS
via CI_CPP, CI_CPP_FLAGS, CI_AR, CI_RANLIB, CI_LD, CI_LD_FLAGS.
For ci_cmake.sh and ci_legacy.sh, customize AR, AR_RC and RANLIB via
CI_AR and CI_RANLIB.
Rewrite portions of ci_legacy.sh to match the style of ci_cmake.sh.
Use standard CMake variables in the install target.
Reformulate comments and error messages.
Move all CMake keywords in front of their arguments.
Fix indentation.
Update the ci_*.sh scripts and move them to the more conventional
ci/ directory. Update .appveyor.yml and .travis.yml, as well as
the AUTHORS file, accordingly.
Speed up ci_cmake.sh: add "-DPNG_TESTS=OFF" to the list of CMake
variables if CI_NO_TEST is true.
Remove "sudo: false" from .travis.yml.
Refactor .appveyor.yml.
Add the CMake option PNG_EXECUTABLES (on by default) in order to
allow or disallow the building of non-essential executable programs
associated with libpng.
Contributed-by: Alex Gaynor <alex.gaynor@gmail.com>
Contributed-by: Cosmin Truta <ctruta@gmail.com>
Signed-off-by: Cosmin Truta <ctruta@gmail.com>
When building with Emscripten, linkage to libm is neither required
nor working. As find_library will fail, M_LIBRARY will be set to
NOTFOUND and the build would fail later. The build works just fine
without libm linkage.
I got a warning while compiling under Ubuntu 18.04 and gcc 7.4:
"__BSD_SOURCE and _SVID_SOURCE are deprecated, use _DEFAULT_SOURCE"
Quote from the Linux Programmer's Manual:
"To allow code that requires _BSD_SOURCE in glibc 2.19 and earlier and
_DEFAULT_SOURCE in glibc 2.20 and later to compile without warnings,
define both _BSD_SOURCE and _DEFAULT_SOURCE."
Problem description:
Imagine a bitstream with an eXIf data segment that has invalid CRC.
If png_crc_finish() fails at line 2090, info_ptr->eXIf_buf is not freed
(despite the free_me setting at line 2062) because png_free_data() is
not called. png_read_info() is actually looping several time over the
png_eXIf chunk, calling png_handle_eXIf() several time in a row without
freeing the buffer.
This patch fixes the problem by leaving info_ptr's content in a clean
state in case of failure, as it is done at line 2084.
Delete variables (ALIGN, ARCH, DOCS) and targets (writelock) that are
no longer necessary.
Reorder the object file lists alphabetically, consistently across all
makefiles and build scripts.
Apply other minor fixes.
Exclude the branch "libpng16" from testing. It's identical to "master".
Also exclude the other (non-current) "libpng[0-1][0-7]" branches.
Parallelize the builds and the unit tests.
For Travis CI, update the build matrix as follows:
* On Linux, use both clang and gcc.
* On macOS, use clang only, with and without Xcode.
For AppVeyor CI, add a build matrix as follows:
* On Windows, use Microsoft Visual Studio 2019 on x86, x64 and arm64.
* Also on Windows, use MSYS2 on x86 and x64.
Use the new scripts/ci_*.sh; remove the old scripts/travis.sh.
