Problem with libz?

[jcharris]

Although I've installed numerous versions of code_saturne on numerous computers, when doing a new setup, I've been stumped... after running the makefile, the relevant bit of error message is:

Linking executable: cs_solver
g++ -o cs_solver -lcs_solver -L/home/jcharris/CS/src/lagr -L/home/jcharris/CS/src/bft -L/home/jcharris/CS/src/gui -L/home/jcharris/CS/src/user -L/home/jcharris/CS/src/fvm -L/home/jcharris/CS/src/turb -L/home/jcharris/CS/src/cdo -L/home/jcharris/CS/src/cogz -L/home/jcharris/CS/src/alge -L/home/jcharris/CS/src/mesh -L/home/jcharris/CS/src/atmo -L/home/jcharris/CS/src/comb -L/home/jcharris/CS/src/cfbl -L/home/jcharris/CS/src/apps -L/home/jcharris/CS/src/elec -L/home/jcharris/CS/src/base -L/home/jcharris/CS/src/pprt -L/home/jcharris/CS/src/darc -L/home/jcharris/CS/src/meg -L/home/jcharris/CS/src/ctwr -L/home/jcharris/CS/src/user_examples -L/home/jcharris/CS/src/rayt -L/home/jcharris/CS/libple/src -O -Wl,-export-dynamic -fopenmp -lsaturne -lple -lz -ldl -L/usr/lib/gcc/x86_64-linux-gnu/11 -L/lib/x86_64-linux-gnu -L/usr/lib/x86_64-linux-gnu -lgfortran -lquadmath -lm -Wl,-rpath -Wl,:/home/jcharris/CS/src/lagr:/home/jcharris/CS/src/bft:/home/jcharris/CS/src/gui:/home/jcharris/CS/src/user:/home/jcharris/CS/src/fvm:/home/jcharris/CS/src/turb:/home/jcharris/CS/src/cdo:/home/jcharris/CS/src/cogz:/home/jcharris/CS/src/alge:/home/jcharris/CS/src/mesh:/home/jcharris/CS/src/atmo:/home/jcharris/CS/src/comb:/home/jcharris/CS/src/cfbl:/home/jcharris/CS/src/apps:/home/jcharris/CS/src/elec:/home/jcharris/CS/src/base:/home/jcharris/CS/src/pprt:/home/jcharris/CS/src/darc:/home/jcharris/CS/src/meg:/home/jcharris/CS/src/ctwr:/home/jcharris/CS/src/user_examples:/home/jcharris/CS/src/rayt:/home/jcharris/CS/libple/src:/usr/lib/gcc/x86_64-linux-gnu/11:/usr/lib/x86_64-linux-gnu
/usr/bin/ld : /home/jcharris/CS/src/apps/libsaturne.so : référence indéfinie vers « gzerror »
/usr/bin/ld : /home/jcharris/CS/src/apps/libsaturne.so : référence indéfinie vers « gzseek »
/usr/bin/ld : /home/jcharris/CS/src/apps/libsaturne.so : référence indéfinie vers « gzeof »
/usr/bin/ld : /home/jcharris/CS/src/apps/libsaturne.so : référence indéfinie vers « gztell »
/usr/bin/ld : /home/jcharris/CS/src/apps/libsaturne.so : référence indéfinie vers « zError »
/usr/bin/ld : /home/jcharris/CS/src/apps/libsaturne.so : référence indéfinie vers « gzopen »
/usr/bin/ld : /home/jcharris/CS/src/apps/libsaturne.so : référence indéfinie vers « gzgets »
/usr/bin/ld : /home/jcharris/CS/src/apps/libsaturne.so : référence indéfinie vers « gzread »
collect2: error: ld returned 1 exit status

It seems to me that it can't find libz... but it is indeed in /usr/lib/x86_64-linux-gnu/ which is one of the folders it looks for.

I presume that I'm making either a very simple error, or have a very system-specific error, but if someone has encountered this before or knows the solution, I would be quite grateful.

[jcharris]

P.S. Now that there is a PyQt6, is there a plan for when this will be adapted into CS?

[Yvan Fournier]

Hello,

Regarding libz, we had a similar issue recently with MED or HDF5. This is related to the way the script cleans up the library search path (assuming everything under /usr is in the default path, which is not true).

This is fixed in the master branch. in V7.0, you can try work around this by adding:
LDFLAGS="-Wl,-rpath -Wl,/usr/lib/x86_64-linux-gnu"

Otherwise, add:

Code: Select all

export LD_LIBRARY_PATH=/usr/lib/x86_64-linux-gnu

in you environment or in the computation preamble in the run.cfg file (see detailed documentation).

I might add the fix in v7.0.6, if feedback on the master branch is good.

As for PyQt6, I started a port last year, but there were still bugs in PyQt6 (things moved Qt6 but not moved yet in Python, leading to crashes), so it was not possible to test/finish the work. Now that PyQt6 should be more mature, we should try work on this again... Hopefully be the release of v8.0. There is an open issue with more details on the internal EDF GitLab repository.

Best regards,

Yvan

[jcharris]

Thanks for the feedback. Though I am a bit confused ; I tried both the LDFLAGS and the LD_LIBRARY_PATH addition already, and it changes nothing. And this is not from v7, but from the current master branch off github.

[Yvan Fournier]

Hello,

I may have mis-read the error message (being biased by the fix I mentioned): it seems that libz is actually loaded (otherwise, we would have a different type of error message indication it was not found), but does not contain the required symbols... So you might be linking to an incomplete stub library.

Can you run "ldd cs_solver" in the failed execution directory and post the output, so as to which which version if libz is found ?

If you are using environment modules, you need to load the first (see if "module load" definitions are present in the "run_solver" file in the same directory).

Best regards,

Yvan

[jcharris]

If I understand correctly, I have not arrived at the point of having cs_solver, that is the next (and last?) step if everything would link, so I'm not sure how to reply.

But if it's useful, I can see (I'm building in ~/CS/, source in ~/code_saturne/):

~/CS$ nm -D /usr/lib/x86_64-linux-gnu/libz.so | grep gzerror
0000000000011150 T gzerror
~/CS$ nm /usr/lib/x86_64-linux-gnu/libz.a | grep gzerror
0000000000000980 T gzerror

And I can see:

~/CS$ ldd src/apps/*.so
src/apps/libcs_solver-7.3.so:
linux-vdso.so.1 (0x00007ffcbfbe6000)
libsaturne-7.3.so => not found
libgomp.so.1 => /usr/lib/x86_64-linux-gnu/libgomp.so.1 (0x00007f060d563000)
libc.so.6 => /usr/lib/x86_64-linux-gnu/libc.so.6 (0x00007f060d33b000)
/lib64/ld-linux-x86-64.so.2 (0x00007f060d5d5000)
src/apps/libcs_solver.so:
linux-vdso.so.1 (0x00007ffdf52f1000)
libsaturne-7.3.so => not found
libgomp.so.1 => /usr/lib/x86_64-linux-gnu/libgomp.so.1 (0x00007f1a3d031000)
libc.so.6 => /usr/lib/x86_64-linux-gnu/libc.so.6 (0x00007f1a3ce09000)
/lib64/ld-linux-x86-64.so.2 (0x00007f1a3d0a3000)
src/apps/libsaturne-7.3.so:
linux-vdso.so.1 (0x00007fffa6fe1000)
libple.so.2 => not found
libgfortran.so.5 => /usr/lib/x86_64-linux-gnu/libgfortran.so.5 (0x00007fd083b3b000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007fd083911000)
libm.so.6 => /usr/lib/x86_64-linux-gnu/libm.so.6 (0x00007fd08382a000)
libgomp.so.1 => /usr/lib/x86_64-linux-gnu/libgomp.so.1 (0x00007fd0837e0000)
libc.so.6 => /usr/lib/x86_64-linux-gnu/libc.so.6 (0x00007fd0835b6000)
libquadmath.so.0 => /usr/lib/x86_64-linux-gnu/libquadmath.so.0 (0x00007fd08356e000)
libgcc_s.so.1 => /usr/lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007fd08354e000)
/lib64/ld-linux-x86-64.so.2 (0x00007fd084da2000)
src/apps/libsaturne.so:
linux-vdso.so.1 (0x00007ffec2dfa000)
libple.so.2 => not found
libgfortran.so.5 => /usr/lib/x86_64-linux-gnu/libgfortran.so.5 (0x00007f93adfb0000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f93add86000)
libm.so.6 => /usr/lib/x86_64-linux-gnu/libm.so.6 (0x00007f93adc9f000)
libgomp.so.1 => /usr/lib/x86_64-linux-gnu/libgomp.so.1 (0x00007f93adc55000)
libc.so.6 => /usr/lib/x86_64-linux-gnu/libc.so.6 (0x00007f93ada2b000)
libquadmath.so.0 => /usr/lib/x86_64-linux-gnu/libquadmath.so.0 (0x00007f93ad9e3000)
libgcc_s.so.1 => /usr/lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f93ad9c3000)
/lib64/ld-linux-x86-64.so.2 (0x00007f93af217000)

[Yvan Fournier]

Hello,

This is quite strange. It may be interesting to set:
LDFLAGS="-Wl,--verbose"
in the configure options, to make the link more verbose so as to understand where errors are coming from.

I suspect the build is trying to link with a wrong, incomplete, or incompatible libz, but do not see how/where the issue might be. A more verbose link output may help analyze this.

Also, what type of system are you running on ? Could you post your config.log file ?

Best regards,

Yvan

[jcharris]

Thanks for the continued suggestions. This is a new laptop that started with Ubuntu 20, upgraded to Ubuntu 22, then tried to install code_saturne. Can describe in more detail if useful.

I attach the config.log file for now, I'll try the flag suggestion and redo from the beginning later this weekend.

[niuniuaba]

Hi there,

I can reproduce this error in Ubuntu 22.04, CS-7.3 alpha from github (7.2.0 does NOT have this problem). If you don't mind to have mpi support here is a possible workaround:

Code: Select all

../configure \
--prefix=/home/jcharris/CS \
--with-mpi=/usr \
--with-mpi-lib=/usr/lib/x86_64-linux-gnu \
--with-mpi-include=/usr/lib/x86_64-linux-gnu/openmpi/include

else, try 7.2.0 first if you don't intend to try a version which is still in alpha.

Some thoughts:
1) it reads in the last line of config.log

Code: Select all

configure: exit 1

That's not good right? It's usually expected to be 'exit 0'. It's hard to tell what's wrong after looking through the whole log.
2) libz is detected in configure stage (or even loaded in compile stage) but somehow libsaturne-7.3.so was not linked to it during compilation. That's for sure because libz.so.1 doesn't show up in the output of command 'ldd libsaturne-7.3.so'.
3) so there must be something wrong in the linking process during compilation. It seems cs-7.3 uses a python script (build-aux/cs_link_library.py) rather than libtool to handle the linking process. This python script accepts linker, which, is set to g++ rather than gcc, as an option. I am not sure if this is the cause.
4) If the workaround doesn't work, I suggest

Code: Select all

make > make.log 2>&1

to see if there is any clue in the log.

Good luck.

[Yvan Fournier]

Hello,

I can reproduce the issue on an Ubuntu 22 VM, and the issue is subtle:
Running:

g++ --verbose -o cs_solver -lcs_solver -L/home/yvan/code_saturne/src/cogz -L/home/yvan/code_saturne/src/meg -L/home/yvan/code_saturne/src/user_examples -L/home/yvan/code_saturne/src/pprt -L/home/yvan/code_saturne/src/ctwr -L/home/yvan/code_saturne/src/base -L/home/yvan/code_saturne/src/darc -L/home/yvan/code_saturne/src/lagr -L/home/yvan/code_saturne/src/user -L/home/yvan/code_saturne/src/elec -L/home/yvan/code_saturne/src/turb -L/home/yvan/code_saturne/src/comb -L/home/yvan/code_saturne/src/atmo -L/home/yvan/code_saturne/src/bft -L/home/yvan/code_saturne/src/mesh -L/home/yvan/code_saturne/src/cfbl -L/home/yvan/code_saturne/src/gui -L/home/yvan/code_saturne/src/fvm -L/home/yvan/code_saturne/src/alge -L/home/yvan/code_saturne/src/cdo -L/home/yvan/code_saturne/src/apps -L/home/yvan/code_saturne/src/rayt -L/home/yvan/code_saturne/libple/src -O -Wl,-export-dynamic -fopenmp -lsaturne -lple -lz -ldl -L/usr/lib/gcc/x86_64-linux-gnu/11 -L/lib/x86_64-linux-gnu -L/usr/lib/x86_64-linux-gnu -lgfortran -lquadmath -lm -Wl,--verbose > cs_link_issue.txt

To get verbose link, I get the attached file, which contains the following lines:

attempt to open /lib/x86_64-linux-gnu/libz.so succeeded
/lib/x86_64-linux-gnu/libz.so

So libz is found... But libz is missing from the link command of libsaturne, and this is what seems to be causing the issue (if I force it manually in the Makefile by adding "-lz" after "$(FCLIBS)" in the definition of LDADD_SATURNE, the final link works.

I'll fix the Makefile generation tomorrow.

Best regards,

Yvan