Use dynamic contrib libraries as default?

[hroest]

When using the boost libraries provided by ubuntu for example, OpenMS compilation fails. I have run into this issue quite often, and frankly its annoying:

/usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/4.8/../../../x86_64-linux-gnu/libboost_math_c99.a(erf.o): relocation R_X86_64_32 against `_ZGVZN5boost4math6detail7erf_impIeNS0_8policies6policyINS3_12domain_errorILNS3_17error_policy_typeE1EEENS3_10pole_errorILS6_1EEENS3_14overflow_errorILS6_1EEENS3_16evaluation_errorILS6_1EEENS3_14rounding_errorILS6_1EEENS3_13promote_floatILb0EEENS3_14promote_doubleILb0EEENS3_14default_policyESK_SK_SK_SK_SK_EEEET_SM_bRKT0_RKN4mpl_4int_ILi53EEEE1Q' can not be used when making a shared object; recompile with -fPIC

you have to remember to use -DBOOST_USE_STATIC=OFF when configuring, however the error only occurs at the very end of the compile cycle. It would be nice to fix this by either

1. use shared libs by default (in Linux at least)
2. detecting unmatched options at configure time by checking whether static boost is compatible
3. compile a "sentinel" library whose only job is to fail if boost is detected wrongly and give the user a sensible error message

It seems that the "Linux way" would be to do (1) since static libraries are not really designed to be used in a shared library and it comes with several drawbacks. So if somebody is compiling and linking on Linux, then it is quite likely that they would like to link boost shared libraries and not static libraries and the default option (static boost) breaks all kinds of things on Linux. The only advantage that I can see is if you are building OpenMS to distribute to other peoples computers where you want as few libs as possible to distribute. However, this usecase is not very common on Linux.

Also an option would be to implement (2) or (3)

[lopippo]

Greetings, I have the same problem on Debian testing right now.

Indeed, cmake ../openms-20180418-git-c618e0b1 -DBOOST_USE_STATIC=0 fixes the linking step. However, I think that on GNU/Linux the typical way of doing is to link to shared object libraries by default. Static library linking brings with it security problems that are not easy to manage from a system integration standpoint, so that we try to avoid static linking by default if possible.

So yes, +1 for dynamic shared object linking on GNU/Linux.

Sincerely, Filippo

[jpfeuffer]

I agree here. Recently I encountered even more trouble with static libraries. I thought it would be a good idea to support them for hassle-free shipping but they come with more problems than they solve. Problems:

• You have to be careful with compile flags (see this issue)
• If functions from the static libraries are only used/included in headers of OpenMS they are not automatically exported in our dynamic library (see zlib issue)
• Problems when linking to OpenMS (with static Xerces) and Xerces (even in the same version) as it seems to generate global objects twice. Even worse when people want to link to different versions I guess.

Things to do:

• Default to shared contrib.
• Prefer or only look for shared library suffixes by setting CMAKE_FIND_LIBRARY_SUFFIXES
• Add code to windows to install all libraries that were linked statically (see my script for pyOpenMS). Currently the windows packaging assumes that everything is built statically. On Mac this is done via our copy dependencies script. On deb we use dpkg-shlibdeps and should not ship libs. RPM does not work yet anyhow (but I guess mostly a dependency list is missing).

[lopippo]

Greetings, 2 years + later...

I am currently trying to package version 2.8.0 for Debian. When I run the following configuration command line: cmake -DCMAKE_BUILD_TYPE=Release ../../development I stumble upon the same problem as described by Hannes long ago.

Now, I grep boost in the CMake files and find this bit of configuration in cmake/build_system_macros.cmake:

36 ## export a single option indicating if boost static libs should be preferred
37 option(BOOST_USE_STATIC "Use Boost static libraries." ON)

When I s/ON/OFF/, and run the same config command above in a pristine build directory, I get the same linking error. If I actually run the configuration command with the -DBOOST_USE_STATIC=OFF switch, the build completes fine.

This is problematic, or not ?

Sincerely, Filippo Rusconi

[jpfeuffer]

Hi! First of all, thank you for your efforts. Apparently, there is another shadowing "option definition" of BOOST_USE_STATIC in the top-level CMakeLists.txt. We definitely should remove one.

Pros of top-level:

• Easier to see all config options in one place.
• Var is definitely available everywhere in downstream included cmake scripts

Pro of build_system_macros:

• It is defined where it is needed but maybe you need some CMake tricks to make the configuration available upstream.

[lopippo]

Greetings, Julianus, thank you for your reply. I will configure the software with the -DBOOST_USE_STATIC=OFF switch for the time being, as I used to do. This is not a problem per se. I was pointing a "cognitive dissonance", here :-) Sincerely, Filippo

[jpfeuffer]

Haha no worries. I would have been confused as well!

Btw: I still vote for making OFF the default, too. But this needs some testing so internal CI does not break.