Re: [boost] Encoding address-model in library names

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

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

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 
folder

As for the change itself, I welcome it -- it's not hard to work around 
the current behaviour (https://stackoverflow.com/a/42408982/43534) 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.