Problem building lal on 32-bit powerpc architecture
I know that this is not relevant for the platforms currently in use. Yet. Since I want to investigate different architectures, as I had done before, I'm also looking into hardware I can get hold of now before proceeding to machines that need to be purchased for big bucks. I came across this abandoned PPC machine (a PowerBook G4), and it turned out that, after performing some hardware maintenance first, it would actually run Debian (Jessie for now), so I went ahead and started to re-build all those packages on my disk ... with quite some success.
Quite unexpectedly though, lal became a show-stopper, and I'm curious what the exact reason(s) might be. Here's the relevant part of the build log:
if env CCACHE_CPP2=1 /usr/bin/swig -octave -globals . -DSWIG_CPLUSPLUS_CAST -outdir swiglal_octave/ -Werror -Wextra -w314,506,511 -I../include -D_ISOC99_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_LIMIT_MACROS -D_FORTIFY_SOURCE=2 -MP -MD -MT swiglal_octave.cpp -MF ./.swigdeps/swiglal_octave.deps.tmp -o swiglal_octave.cpp swiglal.i; then \
mv -f ./.swigdeps/swiglal_octave.deps.tmp ./.swigdeps/swiglal_octave.deps; \
else \
rm -f ./.swigdeps/swiglal_octave.deps.tmp; \
rm -f swiglal_octave.cpp; \
exit 1; \
fi
/bin/bash ../libtool --tag=CXX --tag=disable-static --mode=compile g++ -DHAVE_CONFIG_H -I/usr/include/octave-3.8.2/octave -shared -I. -I../include -D_ISOC99_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_LIMIT_MACROS -D_FORTIFY_SOURCE=2 -D_FORTIFY_SOURCE=2 -I/usr/include/octave-3.8.2/octave/.. -I/usr/include/hdf5/serial -D_FORTIFY_SOURCE=2 -fPIC -I/usr/include/octave-3.8.2/octave/.. -I/usr/include/octave-3.8.2/octave -I/usr/include/hdf5/serial -I/usr/include/mpi -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -pthread -fopenmp -Wno-uninitialized -Wno-unused-variable -Wno-unused-but-set-variable -Wno-format-extra-args -Wno-tautological-compare -Wno-deprecated-declarations -fno-strict-aliasing -O0 -Wp,-U_FORTIFY_SOURCE -g -O2 -fPIE -fstack-protector-strong -Wformat -Werror=format-security -MT swiglal_octave_la-swiglal_octave.lo -MD -MP -MF .deps/swiglal_octave_la-swiglal_octave.Tpo -c -o swiglal_octave_la-swiglal_octave.lo `test -f 'swiglal_octave.cpp' || echo '/tmp/buildd/lal-6.19.2/swig/'`swiglal_octave.cpp
libtool: compile: g++ -DHAVE_CONFIG_H -I/usr/include/octave-3.8.2/octave -I. -I../include -D_ISOC99_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_LIMIT_MACROS -D_FORTIFY_SOURCE=2 -D_FORTIFY_SOURCE=2 -I/usr/include/octave-3.8.2/octave/.. -I/usr/include/hdf5/serial -D_FORTIFY_SOURCE=2 -fPIC -I/usr/include/octave-3.8.2/octave/.. -I/usr/include/octave-3.8.2/octave -I/usr/include/hdf5/serial -I/usr/include/mpi -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -pthread -fopenmp -Wno-uninitialized -Wno-unused-variable -Wno-unused-but-set-variable -Wno-format-extra-args -Wno-tautological-compare -Wno-deprecated-declarations -fno-strict-aliasing -O0 -Wp,-U_FORTIFY_SOURCE -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -MT swiglal_octave_la-swiglal_octave.lo -MD -MP -MF .deps/swiglal_octave_la-swiglal_octave.Tpo -c swiglal_octave.cpp -fPIC -DPIC -o .libs/swiglal_octave_la-swiglal_octave.o
In file included from swiglal_octave.cpp:2759:0:
../include/lal/Factorial.h:133:1: warning: this decimal constant is unsigned only in ISO C90
static const UINT8 LAL_FACT2[] = { \
^
swiglal_octave.cpp: In function 'bool SWIG_init_user(octave_swig_type*)':
swiglal_octave.cpp:225711:13: note: variable tracking size limit exceeded with -fvar-tracking-assignments, retrying without
static bool SWIG_init_user(octave_swig_type* module_ns)
^
At global scope:
cc1plus: warning: unrecognized command line option "-Wno-tautological-compare"
/tmp/cceOHFNd.s: Assembler messages:
/tmp/cceOHFNd.s:5423806: Error: operand out of range (0x0000000000008000 is not between 0xffffffffffff8000 and 0x0000000000007fff)
/tmp/cceOHFNd.s:5423825: Error: operand out of range (0x0000000000008004 is not between 0xffffffffffff8000 and 0x0000000000007fff)
/tmp/cceOHFNd.s:5424437: Error: operand out of range (0x0000000000008008 is not between 0xffffffffffff8000 and 0x0000000000007fff)
/tmp/cceOHFNd.s:5425181: Error: operand out of range (0x000000000000800c is not between 0xffffffffffff8000 and 0x0000000000007fff)
/tmp/cceOHFNd.s:5425316: Error: operand out of range (0x0000000000008010 is not between 0xffffffffffff8000 and 0x0000000000007fff)
/tmp/cceOHFNd.s:5425335: Error: operand out of range (0x0000000000008014 is not between 0xffffffffffff8000 and 0x0000000000007fff)
/tmp/cceOHFNd.s:5425353: Error: operand out of range (0x0000000000008018 is not between 0xffffffffffff8000 and 0x0000000000007fff)
... and this continues for quite some time (1040 lines, to be exact). The number out of range is not incrementing only (as the snippet above might suggest). I'll make the builds (and logs) available on https://galahad.aei.mpg.de/lsc-powerpc-jessie later...
(FWIW, the 'tracking size limit' had also shown up during the amd64 build.)
All those operands are slightly larger than a signed 16-bit number would allow for, so this to me seems to point at a sizeof related thing, which may be due to (a) number types being declared in a wrong way (we had seen this with arm64 in another "corner" case before), or (b) relative jumps that would have to fit into 16 bits (interpreting the out-of-range numbers as offsets would better match their pattern).
What looks rather alarming to me is that the assembly source looks terribly huge (5.5 million lines).
I haven't built LALsuite for i386 for quite some time anymore (IIRC LSC has dropped i386 for lscsoft even before Wheezy), thus I cannot be sure whether this problem would also show up for a 32-bit Intel platform, and I don't intend to find out about it the hard way...
Can someone with more insight into the code please get in touch with me, for more details, and possibly suggestions how to nail this down?