zlib built with EasyBuild yields "no version information available" error message when it's being used

[boegel]

For example:

/home/kehoste/.local/easybuild/software/zlib/1.2.7-goalf-1.1.0-no-OFED/lib/libz.so.1: no version information available

also see http://superuser.com/questions/305055/how-to-diagnosis-and-resolve-usr-lib64-libz-so-1-no-version-information-avail

This is caused by programs/libraries that both use zlib and other (system) libraries at the same time.

The linker ld notices that another library was linked against another version of zlib, and spit out this error message.

Since the error message is printed every time libz.so is loaded, this is annoying. Also, sometimes it breaks things, for example during the PETSc build (it thinks the ar archiver doesn't work properly because the "no version information available" error message is being printed when ar is tested).

[boegel]

To reproduce this, load a zlib module built with EasyBuild, and then use a tool that links with both zlib and a library linked with the system zlib:

[kehoste@ca60c171 ~]$ module list
No Modulefiles Currently Loaded.
[kehoste@ca60c171 ~]$ module load zlib
[kehoste@ca60c171 ~]$ ar -V
ar: /home/kehoste/.local/easybuild/software/zlib/1.2.7-goalf-1.1.0-no-OFED/lib/libz.so.1: no version information available (required by /usr/lib64/libbfd-2.21.53.0.1-6.fc16.so)
GNU ar version 2.21.53.0.1-6.fc16 20110716

Also building libbfd is not a sensible option imho, since it's part of binutils.

[JensTimmerman]

But the ar command failing had nothing to do with this?

[boegel]

@JensTimmerman: ar fails in the PETSc build because of this problem. It was just an example, but it is relevant, since it links in zlib.

[JensTimmerman]

644 should fix this

[fgeorgatos]

There is a possibly suitable way about how to handle this issue, mentioned in https://github.com/hpcugent/easybuild-easyconfigs/pull/985 apparently relying on LD_PRELOAD ; debate to be continued...

[xguse]

OK I am adding some further information on possible zlib problems. According to this thread on the Stacks user mail list, the base system's zlib seems to be causing confusion during the ./configure process?

relevant post:

gzbuffer was added to zlib in version 1.2.4. Your compile complains about the missing gzbuffer function, but not, say gzopen, which is called prior to gzbuffer. This would lead me to believe that you potentially have a second zlib.h header on your system that is being found during compile prior to the more recent version. However, the configure script (which runs before the compile) seems to be finding that a newer version is on the system, enabling the use of the gzbuffer function, which otherwise would not be included in the compile.

Specifically, I ended up fixing my problem by listing a specific zlib > 1.2.3 in easyconfig.builddependencies

...
builddependencies = [('zlib', '1.2.7'), ('SAMtools', '1.1'), ('google-sparsehash', '2.0.2')]
...

Hope this saves someone else some time or helps inform the discussion.

Gus

[ebgregory]

We have had this zlib issue here at JSC as well, mainly stemming from the fact that compilers and linkers are picking up a (very old version of a) system-installed zlib when they are built.

This "no version information available" error seems to show up when a user tries to compile or link a program with a compiler/linker that uses the old system version, while one of the dependencies is the newer EasyBuild-installed newer version

We are dealing with it by moving zlib in the dummy/dummy toolchain as a Core package and making it a (hidden) dependency of binutils, and therefore of the compilers and linkers that are build on top of it.

-Eric

---

From: Augustine (Gus) Dunn [notifications@github.com] Sent: Thursday, January 22, 2015 10:53 PM To: hpcugent/easybuild-framework Subject: Re: [easybuild-framework] zlib built with EasyBuild yields "no version information available" error message when it's being used (#108)

OK I am adding some further information on possible zlib problems. According to this threadhttps://groups.google.com/forum/#!msg/stacks-users/DJuEmm9e08k/Elm4RotNCQoJ on the Stackshttp://creskolab.uoregon.edu/stacks/ user mail list, the base system's zlib seems to be causing confusion during the ./configure process?

relevant post:

gzbuffer was added to zlib in version 1.2.4. Your compile complains about the missing gzbuffer function, but not, say gzopen, which is called prior to gzbuffer. This would lead me to believe that you potentially have a second zlib.h header on your system that is being found during compile prior to the more recent version. However, the configure script (which runs before the compile) seems to be finding that a newer version is on the system, enabling the use of the gzbuffer function, which otherwise would not be included in the compile.

Specifically, I ended up fixing my problem by listing a specific zlib > 1.2.3 in easyconfig.builddependencies

... builddependencies = [('zlib', '1.2.7'), ('SAMtools', '1.1'), ('google-sparsehash', '2.0.2')] ...

Hope this saves someone else some time or helps inform the discussion.

Gus

— Reply to this email directly or view it on GitHubhttps://github.com/hpcugent/easybuild-framework/issues/108#issuecomment-71106614.

---

---

Forschungszentrum Juelich GmbH 52425 Juelich Sitz der Gesellschaft: Juelich Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498 Vorsitzender des Aufsichtsrats: MinDir Dr. Karl Eugen Huthmacher Geschaeftsfuehrung: Prof. Dr.-Ing. Wolfgang Marquardt (Vorsitzender), Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt,

Prof. Dr. Sebastian M. Schmidt

---

[wpoely86]

Potential fix is in hpcugent/easybuild-easyconfigs#1350

It would be great if somebody could test it.

[boegel]

fixed by https://github.com/hpcugent/easybuild-easyconfigs/pull/1350