Hi Raphaël,

From the binutils debug log you provided earlier:

== 2017-09-20 10:24:59,360 run.py:441 DEBUG cmd "ldd /cm/shared/apps/easyb/.local/easybuild/software/binutils/2.25-GCCcore-4.9.3/bin/addr2line" exited with exitcode 0 and output:
    linux-vdso.so.1 =>  (0x00002aaaaaaab000)
    libbfd-2.25.so => /cm/shared/apps/easyb/.local/easybuild/software/binutils/2.25/lib/libbfd-2.25.so (0x00002aaaaaaaf000)
    libdl.so.2 => /lib64/libdl.so.2 (0x00002aaaaade9000)
    libc.so.6 => /lib64/libc.so.6 (0x00002aaaaafed000)
    libz.so.1 => /usr/lib64/libz.so.1 (0x00002aaaab3af000)
    /lib64/ld-linux-x86-64.so.2 (0x0000555555554000)

For some reason libz is still being linked dynamically, and it is picking up the one from the OS, rather than having linked statically to the zlib provided through EasyBuild during the build step...

That's a bit weird, since the libz.a was listed on the link line for addr2line:

/bin/sh ./libtool --tag=CC   --mode=link gcc -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Wshadow -O2 -march=native -fPIC  -static-libstdc++ -static-libgcc -L/cm/shared/apps/easyb/.local/easybuild/software/GCCcore/4.9.3/lib64 -L/cm/shared/apps/easyb/.local/easybuild/software/GCCcore/4.9.3/lib -L/cm/shared/apps/easyb/.local/easybuild/software/flex/2.5.39-GCCcore-4.9.3/lib -L/cm/shared/apps/easyb/.local/easybuild/software/Bison/3.0.4-GCCcore-4.9.3/lib -L/cm/shared/apps/easyb/.local/easybuild/software/zlib/1.2.8-GCCcore-4.9.3/lib -L/cm/shared/apps/easyb/.local/easybuild/software/binutils/2.25/lib -o addr2line addr2line.o bucomm.o version.o filemode.o ../bfd/libbfd.la ../libiberty/libiberty.a  -ldl /cm/shared/apps/easyb/.local/easybuild/software/zlib/1.2.8-GCCcore-4.9.3/lib/libz.a
...
libtool: link: gcc -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Wshadow -O2 -march=native -fPIC -static-libstdc++ -static-libgcc -o .libs/addr2line addr2line.o bucomm.o version.o filemode.o -L/cm/shared/apps/easyb/.local/easybuild/software/GCCcore/4.9.3/lib64 -L/cm/shared/apps/easyb/.local/easybuild/software/GCCcore/4.9.3/lib -L/cm/shared/apps/easyb/.local/easybuild/software/flex/2.5.39-GCCcore-4.9.3/lib -L/cm/shared/apps/easyb/.local/easybuild/software/Bison/3.0.4-GCCcore-4.9.3/lib -L/cm/shared/apps/easyb/.local/easybuild/software/zlib/1.2.8-GCCcore-4.9.3/lib -L/cm/shared/apps/easyb/.local/easybuild/software/binutils/2.25/lib ../bfd/.libs/libbfd.so -L/cm/shared/apps/easyb/.local/easybuild/build/binutils/2.25/GCCcore-4.9.3/binutils-2.25/bfd/../libiberty/pic -liberty ../libiberty/libiberty.a -ldl /cm/shared/apps/easyb/.local/easybuild/software/zlib/1.2.8-GCCcore-4.9.3/lib/libz.a -Wl,-rpath -Wl,/cm/shared/apps/easyb/.local/easybuild/software/binutils/2.25-GCCcore-4.9.3/lib

No signs of warning or errors that would explain why the libz.a wasn't actually used...

Can you try diving into the build directory, where addr2line.o & co are located, and running libtool verbosely while you have GCCcore/4.9.3 loaded?

/bin/sh ./libtool --verbose --tag=CC --mode-link gcc ...



regards,

Kenneth


On 29/09/2017 10:02, Philippart Raphaël wrote:
Hello Ward,

Thanks for you response.

I have well the lib.a in each lib version

root@genetic.master01 ~ # find /cm/shared/apps/easyb/.local/easybuild/software/zlib -name libz.a
/cm/shared/apps/easyb/.local/easybuild/software/zlib/1.2.8-goolf-1.7.20/lib/libz.a
/cm/shared/apps/easyb/.local/easybuild/software/zlib/1.2.8-GCC-4.9.3-binutils-2.25/lib/libz.a
/cm/shared/apps/easyb/.local/easybuild/software/zlib/1.2.8-GCCcore-5.4.0/lib/libz.a
/cm/shared/apps/easyb/.local/easybuild/software/zlib/1.2.8-foss-2016b/lib/libz.a
/cm/shared/apps/easyb/.local/easybuild/software/zlib/1.2.8-GCCcore-4.9.3/lib/libz.a
root@genetic.master01 ~ # find  /cm/shared/apps/zlib/ -name libz.a
/cm/shared/apps/zlib/1.2.8/lib/libz.a


root@genetic.master01 ~ # ll /cm/shared/apps/easyb/.local/easybuild/software/zlib/1.2.8-foss-2016b/lib/
total 210
-rw-r--r-- 1 easyb wheel 120566 Jun 14 22:53 libz.a
lrwxrwxrwx 1 easyb wheel     13 Jun 14 22:53 libz.so-> libz.so.1.2.8
lrwxrwxrwx 1 easyb wheel     13 Jun 14 22:53 libz.so.1-> libz.so.1.2.8
-rwxr-xr-x 1 easyb wheel  93728 Jun 14 22:53 libz.so.1.2.8
drwxr-xr-x 2 easyb wheel     20 Jun 14 22:53 pkgconfig

I don’t have the config.log file in my binutils directory…

For the compilation of lib.a, I have these informations in the log

root@genetic.master01 /cm/shared/apps/easyb/.local/easybuild/software/zlib/1.2.8-foss-2016b # cat easybuild/easybuild-zlib-1.2.8-20170614.225309.log | grep fPIC | grep libz gcc -O2 -march=native -fPIC  -D_LARGEFILE64_SOURCE=1 -DHAVE_HIDDEN -o example example.o -L. libz.a gcc -O2 -march=native -fPIC  -D_LARGEFILE64_SOURCE=1 -DHAVE_HIDDEN -o minigzip minigzip.o -L. libz.a gcc -O2 -march=native -fPIC  -D_LARGEFILE64_SOURCE=1 -DHAVE_HIDDEN -o example64 example64.o -L. libz.a gcc -O2 -march=native -fPIC  -D_LARGEFILE64_SOURCE=1 -DHAVE_HIDDEN -o minigzip64 minigzip64.o -L. libz.a gcc -shared -Wl,-soname,libz.so.1,--version-script,zlib.map -O2 -march=native -fPIC  -fPIC -D_LARGEFILE64_SOURCE=1 -DHAVE_HIDDEN -o libz.so.1.2.8 adler32.lo crc32.lo deflate.lo infback.lo inffast.lo inflate.lo inftrees.lo trees.lo zutil.lo compress.lo uncompr.lo gzclose.lo gzlib.lo gzread.lo gzwrite.lo  -lc -L/cm/shared/apps/easyb/.local/easybuild/software/GCCcore/5.4.0/lib64 -L/cm/shared/apps/easyb/.local/easybuild/software/GCCcore/5.4.0/lib -L/cm/shared/apps/easyb/.local/easybuild/software/OpenBLAS/0.2.18-GCC-5.4.0-2.26-LAPACK-3.6.1/lib -L/cm/shared/apps/easyb/.local/easybuild/software/ScaLAPACK/2.0.2-gompi-2016b-OpenBLAS-0.2.18-LAPACK-3.6.1/lib -L/cm/shared/apps/easyb/.local/easybuild/software/FFTW/3.3.4-gompi-2016b/lib gcc -O2 -march=native -fPIC  -D_LARGEFILE64_SOURCE=1 -DHAVE_HIDDEN -o examplesh example.o -L. libz.so.1.2.8 gcc -O2 -march=native -fPIC  -D_LARGEFILE64_SOURCE=1 -DHAVE_HIDDEN -o minigzipsh minigzip.o -L. libz.so.1.2.8 gcc -O2 -march=native -fPIC  -D_LARGEFILE64_SOURCE=1 -DHAVE_HIDDEN -o example example.o -L. libz.a gcc -O2 -march=native -fPIC  -D_LARGEFILE64_SOURCE=1 -DHAVE_HIDDEN -o minigzip minigzip.o -L. libz.a gcc -O2 -march=native -fPIC  -D_LARGEFILE64_SOURCE=1 -DHAVE_HIDDEN -o example64 example64.o -L. libz.a gcc -O2 -march=native -fPIC  -D_LARGEFILE64_SOURCE=1 -DHAVE_HIDDEN -o minigzip64 minigzip64.o -L. libz.a gcc -shared -Wl,-soname,libz.so.1,--version-script,zlib.map -O2 -march=native -fPIC  -fPIC -D_LARGEFILE64_SOURCE=1 -DHAVE_HIDDEN -o libz.so.1.2.8 adler32.lo crc32.lo deflate.lo infback.lo inffast.lo inflate.lo inftrees.lo trees.lo zutil.lo compress.lo uncompr.lo gzclose.lo gzlib.lo gzread.lo gzwrite.lo  -lc -L/cm/shared/apps/easyb/.local/easybuild/software/GCCcore/5.4.0/lib64 -L/cm/shared/apps/easyb/.local/easybuild/software/GCCcore/5.4.0/lib -L/cm/shared/apps/easyb/.local/easybuild/software/OpenBLAS/0.2.18-GCC-5.4.0-2.26-LAPACK-3.6.1/lib -L/cm/shared/apps/easyb/.local/easybuild/software/ScaLAPACK/2.0.2-gompi-2016b-OpenBLAS-0.2.18-LAPACK-3.6.1/lib -L/cm/shared/apps/easyb/.local/easybuild/software/FFTW/3.3.4-gompi-2016b/lib gcc -O2 -march=native -fPIC  -D_LARGEFILE64_SOURCE=1 -DHAVE_HIDDEN -o examplesh example.o -L. libz.so.1.2.8 gcc -O2 -march=native -fPIC  -D_LARGEFILE64_SOURCE=1 -DHAVE_HIDDEN -o minigzipsh minigzip.o -L. libz.so.1.2.8


Raphaël Philippart
Opérations : Systèmes
SeGI - Université de Liège
Allée de la Découverte, 8
Quartier Polytech 1 - Bâtiment B26
4000 Liège
Phone +32-4-366 4981
Fax +32-4-366 2920
Email rphilipp...@uliege.be <mailto:rphilipp...@uliege.be>




Le 27 sept. 2017 à 20:37, Ward Poelmans <wpoel...@gmail.com <mailto:wpoel...@gmail.com>> a écrit :

Hi Raphaël,

On 25-09-17 09:33, Philippart Raphaël wrote:

Do you have an explanation for my zlib problem and his statically link
problem ?
I deleted in the .eb the zlib’s dependency and I have the same result

I'm seeing things like:
checking for library containing zlibVersion... no
checking for library containing dlopen... none required
checking zlib.h usability... no
checking for spawnvpe... yes
checking zlib.h presence...  bg da de eo es fi fr ga hu id it ja ms nl
pt_BR ro ru rw sr sv tr uk vi bg da de eo es fi fr ga hu id it ja ms nl
pt_BR ro ru rw sr sv tr uk vi
checking whether NLS is requested... yes
checking for msgfmt... yes
checking for zlib.h... yes

Can you verify that libz.a is actually present in the zlib module?
And share the 'config.log' of binutils?

I also see a warning about the static library. Normally should libz.a be
compiled with -fPIC, can you check in the build log?

It's a strange case, the build commands seem fine to me. Can you also
check if the libraries in the lib directory don't link to libz.so?

Ward


Reply via email to