Build task: Investigate the key differences between static versus dynamic linking of dependencies like libboost

[maxieds]

I have a couple of initial points to log on this topic. I will still need to do more checking into this topic as I see how the Cmake integration procedure changes the way we build the PMFE sources.

1. The Boost suite of libraries is a general bear to work with, link against, and consistently maintain on the system. As a result, my choice in opting for a local home directory based compile/link sequences on math-mulberry is intended to allow for more custom changes as the code evolves -- ideally, without too much intervention needed by privileged sysadmins on the SOM machines.
2. Steven has pointed out to me, if I recall correctly, that RH does not like to have to maintain custom compiled, or non-very-vanilla, extra-default packages due to their concerns about maintaining the security policies on their enterprise server boxes. I believe that the full range of Boost libraries that we require for linking these PMFEE applications is not easily supported by installing into systemwide directories. This means that dynamic linking to these required libraries becomes complicated by the need to be able to find where they are located, even as users move around their working directories to run the binaries.
3. One way around the local install problem for the dynamic linking case is to try to link just the Boost libraries statically so we no longer need them after they are built. This is itself problematic since static linking of standard system libraries (like -lstdc++,-lpthread) is not typically expected nor supported by default by RH vendors. I am going to have to look at this more when I pick up the Cmake scripts again before next week.

[maxieds]

@ceheitsch
I have an updated build procedure that removes our need to consider this issue in depth:

• Link against the standard shared library object sources built in the user's local home directory
• Use the linker option -Wl,-rpath=/path/to/dynamic/libs/on/disk to specify where by default the exe / binary should search for the resulting non-static object references.

I think that overall this is a much cleaner, and more natural, working solution to the above problem. 😺

[maxieds]

@ceheitsch
Suggesting that we can close out this issue with the (forthcoming) new commit to the CMakeLists.txt file in the cmake-build branch.