lib/libxml2.so.2: undefined reference to `gzopen64@ZLIB_1.2.3.3'

[deOliveira-R]

I was trying to compile a software (Serpent 2 from VTT) out of the spack environment by loading modules for gcc-7.2.0, openmpi-3.0.0 and libgd.

I get the following error message:

/afs/psi.ch/project/fast_lrs/workspace/RND/FB-RND-ACT-17-01/lclrs/spack/opt/spack/linux-scientific6-x86_64/gcc-7.2.0/libxml2-2.9.4-hrhtwdln3ljxgjzmm5p5cwirqhogwn6n/lib/libxml2.so.2: undefined reference to `gzopen64@ZLIB_1.2.3.3'
collect2: error: ld returned 1 exit status
make: *** [sss2] Error 1

However, the program successfully compiles if I also load the module zlib, which is a dependency of libxml2, which is a dependency of openmpi.

This also affects the program execution. If I unload all the modules except zlib, it executes fine. If I unload zlib, I get:

./sss2: /lib64/libz.so.1: version `ZLIB_1.2.3.3' not found (required by /afs/psi.ch/project/fast_lrs/workspace/RND/FB-RND-ACT-17-01/lclrs/spack/opt/spack/linux-scientific6-x86_64/gcc-7.2.0/libxml2-2.9.4-hrhtwdln3ljxgjzmm5p5cwirqhogwn6n/lib/libxml2.so.2)

Would this indicate that libxml2 did not get configured with relative paths to zlib? Is this expected and a current limitation of libxml2 configurations or a package problem? Or neither and I just don't know what I'm doing?

[davydden]

Would this indicate that libxml2 did not get configured with relative paths to zlib?

probably that.

edit: compiler wrappers should inject rpath's so ideally packages built with Spack shall not depend on environment (i.e. LD_LIBRARY_PATH) in any way.

[pkoro]

Hi all,

I just noticed we have the same issue on our setup as well. I can confirm the error with the following compiler/openmpi implementations:

• gcc@5.5.0, openmpi@3.0.0
• gcc@7.2.0, openmpi@3.0.0 (same as original post)

If there is something I can contribute that would aid debugging please let me know. I suppose it should be something in the libxml2 build, right?

[scheibelp]

Knowing the following would be useful:

• The package you were building (i.e. did this fail when building libxml2, or a dependent of libxml2?)
• The output from Spack (specifically if you run with -d e.g. spack -d install...)
• Are you using a spack-built gcc?
• Do you have entries defined in packages.yaml
• an attached spack-build.out log (and depending on that spack-build.env may also be useful) or your own selection from that file (the full file can have more hints)

Can you replicate the results in the original post where you succeed when a zlib module is loaded? If so, is this a module for a spack-built zlib?

[pkoro]

Hi @scheibelp,

• I believe this was produced when building Einstein Toolkit 2017_06 (something outside of Spack). The error appeared during linking. I could proceed with the link by indicating which exact libz to link with (or via loading the modulefile). The libz is the spack provided one.
• Yes, gcc is in both cases Spack built (not the system one).
• No entries in packages.yaml

I don't have spack output files as this was observed when building an application that is not in the Spack manifest. Actually, I don't have any output files but I could re-generate something if needed.

[scheibelp]

I believe this was produced when building Einstein Toolkit 2017_06 (something outside of Spack)

That is useful to know!

FYI RPATHs don't affect linking, only how libraries are found at runtime. When you build a package with Spack it also does work to add -L entries to ensure the linker finds the appropriate libraries; when you build a package outside of Spack you don't get that benefit, which is why you need to load the zlib module to add it to LD_LIBRARY_PATH. There are related approaches like the spack view command (which creates a merged prefix) and #4585 but either way you need additional environment setup.

If you are building this package outside of Spack because you are developing it, then spack setup may be useful to you (it is being updated at #5043)

Anyhow I'm closing this because I think the cause is known and not a Spack bug. But if you disagree feel free to reopen.