- removed comment
Disable shared libraries for all ExternalLibraries
Having a shared library build by an ExternalLibraries thorn means that the executable will not be self-contained, potentially leading to segfaults during long-running simulations.
Keyword:
Comments (11)
-
-
reporter - removed comment
On many such machines we either don't build ourselves, or don't use shared libraries at all.
-
- removed comment
On danger of adding more complication: could this be made an option list option (set in the machine database of simfactory, with non-shared as default), so that on ones workstation (using eg. debian.cfg) one can enable shared libraries even for self-build ExternalLibraries to speed up the linking process and or allow one ExternalLibraries build to be used among several configurations (eg.)?
-
reporter - removed comment
The libraries build by ExternalLibraries live (by default) in the configs subdirectory. A "make clean" will wipe them out, leaving an unusable executable. This must be avoided.
If you place ExternalLibraries results somewhere else, then there is no need to make them static. One can continue to use the library's default setting.
-
- removed comment
I liking the "static" option more and more :-). In particular loosing the shared libraries upon a "clean" sounds inconvenient.
Right now I have a simulation outputting:
Warning! ***HDF5 library version mismatched error*** The HDF5 header files used to compile this application do not match the version used by the HDF5 library to which this application is linked.
since it (on zwicky which is Caltech local) compiled HDF5 but ended up using the system provided HDF5 anyway.
-
- removed comment
I noticed a similar (but different) issue on Datura. Datura uses the system HDF5 location, but when I had an hdf5 module loaded in my modulerc (which I don't usually have), my simulation complained that it was using this version, which is not the version it was compiled against.
-
- removed comment
come to think of this, shouldn't there be a -Wl,-rpath,<PATH> somewhere in the linker's option list that prevents this kind of thing? I think on zwicky I sabotaged myself by having /usr/lib64 in the library folder list for MPI (listed explicitly).
-
- changed status to open
- removed comment
The attached patch compiles OpenMPI statically and also copies mpirun into exe/<configname> so that one can actually run the compiled executable using the proper mpirun command.
-
reporter - removed comment
Please apply.
Please don't close this ticket afterwards... we need to check the other external libraries as well.
-
reporter - changed status to resolved
- removed comment
I believe all external libraries are now built statically.
-
- changed status to closed
- edited description
- Log in to comment
I wonder how that even works on machines without access to the build filesystem from the compute nodes.