[Users] ld error while linking simfactory on a HPC

Haas, Roland rhaas at illinois.edu
Mon Dec 2 12:09:41 CST 2019

Hello Alois,

to fix the DSO error you would have to explicitly mention -ludev on the
linker line, after hwloc. The easiest way to achieve this is to set:


in you option list and either do a recompile from scratch (safest) or
make sure to "touch" all ccl files and src/detect.sh then you *may* be
able to get away with just a --reconfig (or -rebuild if using the bare
Cactus makefile).

If this still does not link, please do:

export VERBOSE=yes

before building the code and append "&>make.log" to your build command
line so that all log output is redirected to a file make.log then
provide that file.

Please also provide the file configs/sim/config-info.

Note that there is a second issue present "libgfortran.so.3, needed by
/lib/../lib64/liblapack.so, may conflict with libgfortran.so.5" which
is due to some libraries (liblapack.so in particular) that you are
using having been compiled with an older version of gfortran (using
libgfortran.so.3 as its runtime library) than the main code (which uses
libgfortran.so.5). To fix this you will either have to use a liblapack
version compiled with the same gfortran version you use for the main
code, or enable thorn ExternalLibraries/OpenBLAS and *disable*
ExternalLibraries/BLAS and ExternalLibraries/LAPACK (since those two
are the reference implementations and are very slow).


> Dear all,
> (1)
> I tried to compile simfactory on a German HPC (HLRN4) at Goettingen
> named "Emmy" - probably from Emmy Noether as she worked a long time there. (She is well-known from the Noether-theorem and abstract algebra)
> Unfortunately linking was not successful:
> ------------------------------------------------------------------------------------
> /usr/bin/ld: warning: libgfortran.so.3, needed by /lib/../lib64/liblapack.so, may conflict with libgfortran.so.5
> /usr/bin/ld: /home/shicfdfh/Einstein-toolkit/Cactus/configs/sim/scratch/external/hwloc/lib/libhwloc.a(topology-linux.o): undefined reference to symbol 'udev_device_unref@@LIBUDEV_183'
> /usr/lib64/libudev.so.1: error adding symbols: DSO missing from command line
> collect2: Fehler: ld gab 1 als Ende-Status zurück
> make[1]: *** [/home/shicfdfh/Einstein-toolkit/Cactus/exe/cactus_sim] Fehler 1
> make: *** [sim] Fehler 2
> -----------------------------------------------------------------------------------
> Remark: "Fehler" is German and means ERROR.
> (2)
> meanwhile I received feedback from our HPC-support:
> He says: libudev.so.1  contains demanded ref to "183" and he asks if the order of options in the specific command-line is right:
> (from stackoverflow)
> "...Explanation: the linking is dependent on the order of modules.
> Symbols are first requested, and then linked in from a library that has them. So you have to specify modules that use libraries first, and libraries after them. "
> I must admit, that I'm not able to locate the line/file to which this might apply
> (3)
> Does anybody have an idea which may resolve the bug ?
> Many thanks in advance advance and best wishes
> Alois Peter from Kiel, Germany

My email is as private as my paper mail. I therefore support encrypting
and signing email messages. Get my PGP key from http://pgp.mit.edu .
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
Url : http://lists.einsteintoolkit.org/pipermail/users/attachments/20191202/69c8a541/attachment.bin 

More information about the Users mailing list