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

Subject: Re: [boost] Boost modular: Build without version number suffixes
From: Robert Dailey (rcdailey.lists_at_[hidden])
Date: 2015-01-26 10:22:52

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)
>
> 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.
>
>
> -Steve
>

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).

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).

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. This inconsistency breaks for me as I've
explained above.

Hope that helps clarify.