Boost logo

Boost :

Subject: Re: [boost] Encoding address-model in library names
From: Gavin Lambert (gavinl_at_[hidden])
Date: 2017-07-06 01:10:53

On 6/07/2017 10:00, Andrey Semashev wrote:
> On 07/06/17 00:16, Peter Dimov wrote:
>> I have prepared the pull requests necessary to encode the
>> address-model (32 or 64) in the library names, which allows placing
>> the 32/64 libraries into the same stage/install directory, and
>> building with address-model=32,64 in one go.
> Does it only include the address model without the architecture? If yes,
> it doesn't really solve the problem since you'll still have the same
> issue when you compile 32-bit x86 and ARM binaries, for example. If we
> want to put binaries to the same directory, I think the name should
> include the architecture.

I guess the question there is how often people build multi-architecture.

On Windows, I see it as relatively common to build both 32-bit and
64-bit applications and libraries.

More importantly, there is an installation scenario where an application
suite might contain a mixture of 32-bit and 64-bit applications, where
it would be convenient to have all the dependent libraries (including
Boost) in the same directory, since Windows has a convention of looking
in the same directory as the original application for its library
dependencies, and you have to jump through a lot of hoops to make it do

On the other hand, at runtime you'd never have x86 and ARM libraries in
the same folder. At build time it's trivial enough to have your x86/64
libraries in one folder and your arm libraries in another; it might be
convenient to have them in one place but I don't see this as compelling
(but then I don't build arm binaries as a matter of course, so take that
with a grain of salt).

So on Windows, there would be a large benefit to discriminating between
32-bit and 64-bit, and little-to-no benefit to discriminating between

On Linux, it's a moot point, since Linux:
   (a) doesn't use the versioned file naming layout, so this change
doesn't affect them in the first place
   (b) does have a convention of storing (and looking for) library
binaries in architecture+model specific folders rather than in the same

As for the change itself, I welcome it -- it's not hard to work around
the current behaviour ( but
it would be nice not to have to.

For most Windows users it shouldn't adversely affect builds (thanks to
auto linking) but install packages and the like would probably need to
be tweaked for filename changes. While this might annoy some people, as
long as it's infrequent and valuable enough (as this seems to be) it
should be fine.

Boost list run by bdawes at, gregod at, cpdaniel at, john at