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
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:
HWLOC_EXTRA_LIBS = udev
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).
Yours, Roland
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
users@lists.einsteintoolkit.org