Re: [boost] [build] Boost modular: Build without version number suffixes

Subject: Re: [boost] [build] Boost modular: Build without version number suffixes
From: Rob Stewart (rob.stewart_at_[hidden])
Date: 2015-01-27 04:39:52

On January 26, 2015 10:22:52 AM EST, Robert Dailey <rcdailey.lists_at_[hidden]> wrote:
> On Mon, Jan 26, 2015 at 12:07 AM, Steve M. Robbins <steve_at_[hidden]>
> wrote:
> > On January 25, 2015 10:48:12 PM Robert Dailey wrote:
> >> When I build modular boost on Linux Mint 17, I get SO files named
> like so:
> >>
> >> libboost_date_time.so.1.57.0
> >>
> >> with a corresponding symlink without the version number:
> >>
> >> libboost_date_time.so
> >
> > That's standard practice on linux.  The SO versioning means you can
> install,
> > say, Boost 1.60 alongside 1.57 and files linked against the older
> version
> > continue to work.  (Boost does not maintain ABI compatibility across
> versions)

Right

> > So ...
> >
> >> I'd like it to build without the version number because when I
> rename
> >> the base file to remove the version, code links fine but during
> >> runtime it tries to load the SO with the version number at the end.
> >
> > .... really curious why you want to do that.
> 
> I have an application that I build on both Windows and Linux. For each
> platform, I compile the dependent libraries (Boost, OpenSSL, etc) on
> each platform and store the binaries in a git submodule (only binaries
> and third party libs are stored in this submodule). I use CMake to
> build this project and having the third party dependencies handled the
> same way on both platforms simplifies my build scripts and, most
> importantly, makes my project build out of the box without having to
> install stuff via package manager (Windows has no such concept
> anyway). It also guarantees that the libraries are always available
> (for example if a version of OpenSSL falls off the edge of the planet,
> I won't be in a crisis since I maintain it myself. This is important
> to an enterprise).

We maintain our own collections of packages, too, but we do so in the filesystem.

> Having explained all of that, I do not need the version numbering in
> boost because different versions do not coexist. My build script looks
> for all *.so files and performs 2 steps:
> 
> * For each SO file found, pass that as a link target to projects in
> CMake that depend on it
> * For each SO file found, copy that to the binary output directory so
> that the executables that depend on those SO files may find them
> (instead of delegating the search to PATH or whatnot).

We do that on Windows and use the binary's RUNPATH to find shared objects on Linux. However, we do reference shared objects in the usual Linux way: unversioned symlink to versioned shared object.

> it seems to me that the way boost builds SO files implies that the SO
> file is meant to be used for linking only and the library that is
> actually dynamically loaded at runtime is not the SO file but the ones
> ending in a version. 

The symlink is unversioned so you implicitly get the version it references without having to link against the versioned shared object. (Your build always mentions the unversioned name.) The Linux linker knows to resolve the symlink and links against the versioned shared object for you. That leads to the runtime reference to the versioned shared object. Two applications linked that way, at different times, can reference different versions of the shared object.

> This inconsistency breaks for me as I've
> explained above.

I understand that you want consistency between platforms. Just beware that fighting the norms of a platform will cause difficulties. That said, ISTR an option for Boost Build to build things as you want, but I don't know what it is. (I added "[build]" to the subject in hopes that will attract the right attention to your query.

___
Rob

(Sent from my portable computation engine)