Discussion:
'ld' failing in builld on debian-s390, but not on zelenka
(too old to reply)
Alastair McKinstry
2010-11-14 11:10:02 UTC
Permalink
Hi,

Is there any way of telling what version of 'ld' was on the debian
buildds (specifically for s390)
for a given build? I have a package, cmor, that has FTBFS on s390 since
2.2.0, for the last four
uploads. It fails in 'ld' building a test that has not changed since
version 2.1, and it builds fine
on zelenka, just not in the buildd. So I can't reproduce it outside the
buildd.

collect2: ld terminated with signal 9 [Killed]
/bin/sh: ./ipcc_test_code: No such file or directory
make[1]: *** [test_C] Error 127
make[1]: Leaving directory `/build/buildd-cmor_2.3.0-1-s390-jwQq7P/cmor-2.3.0'


Any ideas?
--
Alastair McKinstry ,<***@sceal.ie> ,<***@debian.org> http://blog.sceal.ie

Anyone who believes exponential growth can go on forever in a finite world
is either a madman or an economist - Kenneth Boulter, Economist.
Philipp Kern
2010-11-14 11:40:01 UTC
Permalink
Post by Alastair McKinstry
Is there any way of telling what version of 'ld' was on the debian
buildds (specifically for s390)
for a given build? I have a package, cmor, that has FTBFS on s390
since 2.2.0, for the last four
uploads. It fails in 'ld' building a test that has not changed since
version 2.1, and it builds fine
on zelenka, just not in the buildd. So I can't reproduce it outside
the buildd.
All the packages installed are listed in the build log. See "Toolchain package
versions:" and "Package versions:".

Kind regards,
Philipp Kern
Alastair McKinstry
2010-11-14 12:30:03 UTC
Permalink
Post by Philipp Kern
Post by Alastair McKinstry
Is there any way of telling what version of 'ld' was on the debian
buildds (specifically for s390)
for a given build? I have a package, cmor, that has FTBFS on s390
since 2.2.0, for the last four
uploads. It fails in 'ld' building a test that has not changed since
version 2.1, and it builds fine
on zelenka, just not in the buildd. So I can't reproduce it outside
the buildd.
All the packages installed are listed in the build log. See "Toolchain package
versions:" and "Package versions:".
Kind regards,
Philipp Kern
Ok, didn't see that bit marked "Toolchain". Thanks.
So, binutils is 2.20.1-15 on both zelenka and the buildd, lxdebian.
My next guess is memory: It seems to have built fine on zandonai, (2g)
as buildd,
and zelenka (1g?) but failed on lxdebian. I can't find the details of
lxdebian:
in what way might lxdebian be different?

Regards
Alastair
--
To UNSUBSCRIBE, email to debian-s390-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: http://lists.debian.org/***@debian.org
Alastair McKinstry
2010-12-06 13:10:01 UTC
Permalink
Ok,

I rebuilt CMOR: I can build fine by hand on zelenka, but it fails in
lxdebian the buildd.

The failure is in gcc. With gcc --verbose I see:

rm -f test_grid ; gcc --verbose -lnetcdf -Iinclude -Iinclude/cdTime Test/test_grid.c -L/usr/lib -I/usr/include -L. -lcmor -lnetcdf -ludunits2 -lossp-uuid -I/usr/include/ossp -o test_grid ; ./test_grid ;
Using built-in specs.
Target: s390-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.4.5-10' --with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.4 --enable-shared --enable-multiarch --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.4 --libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --with-long-double-128 --enable-targets=all --enable-checking=release --build=s390-linux-gnu --host=s390-linux-gnu --target=s390-linux-gnu
Thread model: posix
gcc version 4.4.5 (Debian 4.4.5-10)
COLLECT_GCC_OPTIONS='-v' '-Iinclude' '-Iinclude/cdTime' '-L/usr/lib' '-I/usr/include' '-L.' '-I/usr/include/ossp' '-o' 'test_grid' '-m31' '-mesa' '-march=g5'
/usr/lib/gcc/s390-linux-gnu/4.4.5/cc1 -quiet -v -Iinclude -Iinclude/cdTime -I/usr/include -I/usr/include/ossp Test/test_grid.c -quiet -dumpbase test_grid.c -m31 -mesa -march=g5 -auxbase test_grid -version -o /tmp/ccdZz2mP.s
ignoring nonexistent directory "/usr/local/include/s390-linux-gnu"
ignoring nonexistent directory "/usr/lib/gcc/s390-linux-gnu/4.4.5/../../../../s390-linux-gnu/include"
ignoring nonexistent directory "/usr/include/s390-linux-gnu"
ignoring duplicate directory "/usr/include"
as it is a non-system directory that duplicates a system directory
#include "..." search starts here:
#include<...> search starts here:
include
include/cdTime
/usr/include/ossp
/usr/local/include
/usr/lib/gcc/s390-linux-gnu/4.4.5/include
/usr/lib/gcc/s390-linux-gnu/4.4.5/include-fixed
/usr/include
End of search list.
GNU C (Debian 4.4.5-10) version 4.4.5 (s390-linux-gnu)
compiled by GNU C version 4.4.5, GMP version 4.3.2, MPFR version 3.0.0-p3.
GGC heuristics: --param ggc-min-expand=72 --param ggc-min-heapsize=79239
Compiler executable checksum: 82d586017d17762bc300fdba943aa26e
Test/test_grid.c: In function 'main':
Test/test_grid.c:144: warning: passing argument 4 of 'cmor_set_grid_mapping' from incompatible pointer type
include/cmor_func_def.h:96: note: expected 'char **' but argument is of type 'char *'
Test/test_grid.c:144: warning: passing argument 7 of 'cmor_set_grid_mapping' from incompatible pointer type
include/cmor_func_def.h:96: note: expected 'char **' but argument is of type 'char *'
COLLECT_GCC_OPTIONS='-v' '-Iinclude' '-Iinclude/cdTime' '-L/usr/lib' '-I/usr/include' '-L.' '-I/usr/include/ossp' '-o' 'test_grid' '-m31' '-mesa' '-march=g5'
as -m31 -mesa -march=g5 -o /tmp/ccsoFO5H.o /tmp/ccdZz2mP.s
COMPILER_PATH=/usr/lib/gcc/s390-linux-gnu/4.4.5/:/usr/lib/gcc/s390-linux-gnu/4.4.5/:/usr/lib/gcc/s390-linux-gnu/:/usr/lib/gcc/s390-linux-gnu/4.4.5/:/usr/lib/gcc/s390-linux-gnu/:/usr/lib/gcc/s390-linux-gnu/4.4.5/:/usr/lib/gcc/s390-linux-gnu/
LIBRARY_PATH=/usr/lib/gcc/s390-linux-gnu/4.4.5/:/usr/lib/gcc/s390-linux-gnu/4.4.5/:/usr/lib/gcc/s390-linux-gnu/4.4.5/../../../../lib/:/lib/../lib/:/usr/lib/../lib/:/usr/lib/gcc/s390-linux-gnu/4.4.5/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-v' '-Iinclude' '-Iinclude/cdTime' '-L/usr/lib' '-I/usr/include' '-L.' '-I/usr/include/ossp' '-o' 'test_grid' '-m31' '-mesa' '-march=g5'
/usr/lib/gcc/s390-linux-gnu/4.4.5/collect2 --build-id --eh-frame-hdr -m elf_s390 --hash-style=both -dynamic-linker /lib/ld.so.1 -o test_grid /usr/lib/gcc/s390-linux-gnu/4.4.5/../../../../lib/crt1.o /usr/lib/gcc/s390-linux-gnu/4.4.5/../../../../lib/crti.o /usr/lib/gcc/s390-linux-gnu/4.4.5/crtbegin.o -L/usr/lib -L. -L/usr/lib/gcc/s390-linux-gnu/4.4.5 -L/usr/lib/gcc/s390-linux-gnu/4.4.5 -L/usr/lib/gcc/s390-linux-gnu/4.4.5/../../../../lib -L/lib/../lib -L/usr/lib/../lib -L/usr/lib/gcc/s390-linux-gnu/4.4.5/../../.. -lnetcdf /tmp/ccsoFO5H.o -lcmor -lnetcdf -ludunits2 -lossp-uuid -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/lib/gcc/s390-linux-gnu/4.4.5/crtend.o /usr/lib/gcc/s390-linux-gnu/4.4.5/../../../../lib/crtn.o
collect2: ld terminated with signal 9 [Killed]
/bin/sh: ./test_grid: No such file or directory
make[1]: *** [test_C] Error 127
make[1]: Leaving directory `/build/buildd-cmor_2.5.1-1-s390-b1PcpV/cmor-2.5.1'
dh_auto_test: make -j1 test returned exit code 2
make: *** [build] Error 29

dpkg-buildpackage: error: debian/rules build gave error exit status 2


So it fails with a segfault in gcc, but I suspect this is memory
related, as it works in Zelenka. Can anyone check further?
--
Alastair McKinstry ,<***@sceal.ie> ,<***@debian.org> http://blog.sceal.ie

Anyone who believes exponential growth can go on forever in a finite world
is either a madman or an economist - Kenneth Boulter, Economist.
Loading...