[tlbuild] aarch64/armv8h binary distribution?

[Johannes Hielscher]

Am Sat, 14 Oct 2017 21:50:07 GMT
schrieb Karl Berry <karl at freefriends.org>:

> Hi Johannes,
> 
> Thanks for all the info. Should be no problem to add once the build
> succeeds.
> 
>     checking for png_create_read_struct... no
>     configure: error: libpng not found
> 
> Please look at gd/config.log (search for png_create or whatever); the
> exact test program being run, compiler invocation, and error messages
> should be there. I can't guess.

Thanks for the hint. It would have been too easy to just look at the
respective logs in the first place…

gd/config.log:

configure:5894: checking for png_create_read_struct
configure:5894: gcc -o conftest -mtune=generic -O2 -pipe
-I$BUILDROOT/Build/source/Work/libs/libpng/include
-I$BUILDROOT/Build/source/Work/libs/zlib/include   conftest.c
$BUILDROOT/Build/source/Work/libs/libpng/libpng.a
$BUILDROOT/Build/source/Work/libs/zlib/libz.a -lm  >&5
$BUILDROOT/Build/source/Work/libs/libpng/libpng.a(pngrutil.o): In
function `png_read_filter_row': pngrutil.c:(.text+0x42dc): undefined
reference to `png_init_filter_functions_neon'


So the error is not gd not finding libpng, but indeed libpng not
properly handling the presence of NEON instructions on AArch64.

There has been an (apparently related) bug upstream [0], which has been
fixed since 1.6.15, i. e. three years ago.

In fact, building libpng within source/libs/libpng/libpng-src via
  cmake . -DPNG_ARM_NEON; make
builds the library including NEON bindings (nm libpng.a | grep neon),
but all my efforts [1] to inject -DPNG_ARM_NEON into libpng's CPPFLAGS
could not convince the TL build system to include NEON bindings into
libpng [2].
What am I doing wrong? What would be the proper way to
configure the sub-libraries? I couldn't make sense of README.4layout,
sect. 6.3.5 (at least not enough to fix libpng build).


Thanks,
Johannes



[0] https://sourceforge.net/p/libpng/bugs/230/ Apparently, the
tests and includes introduced there have not been backported to TL's
own libpng build system---I doubt if this trouble is just about this
logic just missing here.

[1] TL_CONFIGURE_ARGS="--enable-arm-neon=yes"; distributing
"-DPNG_ARM_NEON" at the appropriate places in m4/kpse-libpng-flags.m4,
libs/libpng/{Makefile.am,configure.ac,configure},
libs/libpng/libpng-src/Makefile.am libs/gd/configure.ac;
running ./reautoconf; including @LIBPNG_TREE@/arm/arm_init.c into
libpng/Makefile.{in,am} and @LIBPNG_TREE@/arm/arm_init.$(OBJEXT) into
libpng/Makefile.in [3]

[2] Even worse: libpng.a successfully (!) builds, but has internal
references to functions from libpng-src/arm/arm_init.c etc., that are
not included at all. This breaks things at runtime without warning.
Fortunately, gd tested for this, before end users did \-:

[3] This last-resort step breaks build of libpng itself, with the error:
../../../libs/libpng/libpng-src/arm/arm_init.c:133:1: fatal error:
opening dependency file libpng-src/ar m/.deps/arm_init.Tpo: No such
file or directory
However, the inclusion of arm/arm_init.c should already be managed by
the existence of PNG_ARM_NEON (see ll. 95--98 in libpng-src/Makefile.am
for the upstream approach to this).

> 
>     --{en,dis}able--gl ; which one is better suited?).
> 
> --enable is preferred, when it works.
> (Briefly discussed at http://tug.org/texlive/build.html#asymptote)
> 
> Happy building,
> Karl