This file contains hand-coded assembler implementations of the filter
functions for 32-bit Arm platforms. These are only used when the
compiler doesn't support neon intrinsics (added to GCC 4.3 in 2008) or
is exactly GCC 4.5.4 (released 2012), both of which are sufficiently
unlikely to be true that it's fair to say the assembler is no longer
used.
This commit deletes filter_neon.S and removes the now obsolete
preprocessor logic in pngpriv.h.
Signed-off-by: Bill Roberts <bill.roberts@arm.com>
Signed-off-by: Cosmin Truta <ctruta@gmail.com>
This fixes the bug https://github.com/pnggroup/libpng/issues/505
"libpng does not support PAC/BTI on aarch64 targets" which arises
because the build mechanisms (both cmake and configure) assemble
arm/filter_neon.S even though it ends up completely empty. The empty
file effectively poisons the so that the PAC/BTI support gets disabled.
The fix is minimal; it simply removes arm/filter_neon.S from the list of
sources included in the 64-bit ARM builds build. Note that this was
already done in cmake for MSVC - it's not clear whether this change was
a partial fix for the same issue.
This version of the fix ONLY affects aarch64 (arm64) builds; 32-bit ARM
systems can still invoke the assembler if required and, indeed, there
should be no change whatsover to those builds.
The assembler code could not be used on 64-bit systems in any case so
in practice there is no material change to 64-bit builds either.
TESTING: pull the changes then type "autoreconf" if using configure (not
required for cmake).
TESTS: cmake has not been tested because cross-builds with cmake
currently fail to find the zlib installation from the cmake system root
path. The following has been tested with configure cross builds:
armv7-linux-gnueabi [no neon support]
armv7a-linux-gnueabi [no neon support]
armv7a-hardfloat-linux-gnueabi [neon support not enabled]
armv7a-hardfloat-linux-gnueabi -mfpu=neon [uses intrinics]
armv7a-hardfloat-linux-gnueabi -mfpu=neon
-DPNG_ARM_NEON_IMPLEMENTATION=2 [uses assembler]
aarch64-linux-gnu [uses intrinsics]
aarch64-linux-gnu -DPNG_ARM_NEON_OPT=0 [neon support disabled]
Signed-off-by: John Bowler <jbowler@acm.org>
Move all Autoconf macro files (except for those that need to be in
the top-level directory) to their own subdirectory scripts/autoconf/
In this commit, we introduce a better way to organize the scripts dir,
and we make a better separation between the build scripts under the
libpng license vs. the build scripts that fall under other licenses.
Please see scripts/autoconf/README.md for more information.
Rename
--enable-png-tests/--disable-png-tests
--enable-png-tools/--disable-png-tools
to
--enable-tests/--disable-tests
--enable-tools/--disable-tools
respectively.
While the `PNG_` prefix is necessary in CMakeLists.txt, a corresponding
`--...-png-` option qualifier would be redundant in a configure script.
This PR adds two set of options to the configure script:
--enable-png-tests/--disable-png-tests
and
--enable-png-tools/--disable-png-tools
By using this feature, a user will be allowed to build only library if
needed, which will be useful on platforms not able to build the tools
and/or the tests.
This PR leaves the existing behaviour as default setting, by building
both the tools and the tests if the options are not used.
CMakeLists.txt already supports this feature with the options PNG_TESTS
and PNG_EXECUTABLES. After this commit, Autotools will provide the same
feature.
Signed-off-by: Cosmin Truta <ctruta@gmail.com>
It is unreliable to run pngtest in parallel, due to competing writes
to the same intermediate/output file ("pngout.png").
Customization of this output file name should be possible, but it is
currently broken.
This adds pngcp to the build together with a pngcp.dfa configuration test; the
test revealed some configuration bugs which are fixed by corrections to the
_SUPPORTED macros.
pngcp builds on all tested configurations and a number of bugs have been fixed
to make this happen relative to the version in libpng 1.7 contrib/examples.
pngcp.dfa will have to be different for 1.7 but pngcp.c should work fine (not
yet tested). pngcp itself is still missing a usage message; this is a
preliminary version, although since it behaves the same way as 'cp' most unoids
shouldn't have a problem using it correctly.
Signed-off-by: John Bowler <jbowler@acm.org>
tests/pngstest-* are changed so that the new test files are divided into 8
groups by gamma and alpha channel. This makes each test take just under 5
seconds on a moderately up-to-date x86_64 system using libpng16 (test times are
somewhat variable under libpng17 at present because of the lack of optimization
in some gamma processing paths.)
These tests have considerably better code and pixel-value coverage than
contrib/pngsuite however coverage is still incomplete.
Signed-off-by: John Bowler <jbowler@acm.org>
configure. In configure builds 'make install' changes/adds links like png.h
and libpng.a to point to the newly installed, versioned, files (e.g.
libpng17/png.h and libpng17.a). Three new configure options and some
rearrangement of Makefile.am allow creation of these links to be disabled.
1) Added the 'compile' program to the list of programs that must be cleaned
in autogen.sh
2) Added 'subdir-objects' which causes .c files in sub-directories to be
compiled such that the corresponding .o files are also in the
sub-directory. This is because automake 1.14 warns that the
current behavior of compiling to the top level directory may be removed
in the future.
3) Updated dependencies on pnglibconf.h to match the new .o locations and
added all the files in contrib/libtests and contrib/tools that depend
on pnglibconf.h
4) Added 'BUILD_SOURCES = pnglibconf.h'; this is the automake recommended
way of handling the dependencies of sources that are machine generated;
unfortunately it only works if the user does 'make all' or 'make check',
so the dependencies (3) are still required.
