Disable shared libraries for all ExternalLibraries

Create issue
Issue #1272 closed
Erik Schnetter created an issue

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)

  1. Frank Löffler
    • removed comment

    I wonder how that even works on machines without access to the build filesystem from the compute nodes.

  2. Erik Schnetter reporter
    • removed comment

    On many such machines we either don't build ourselves, or don't use shared libraries at all.

  3. Roland Haas
    • 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.)?

  4. Erik Schnetter 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.

  5. Roland Haas
    • 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.

  6. Ian Hinder
    • 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.

  7. Roland Haas
    • 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).

  8. Roland Haas
    • 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.

  9. Erik Schnetter reporter
    • removed comment

    Please apply.

    Please don't close this ticket afterwards... we need to check the other external libraries as well.

  10. Log in to comment