Re: [boost] 32/64 library name conflict under Windows?

Subject: Re: [boost] 32/64 library name conflict under Windows?
From: Paul A. Bristow (pbristow_at_[hidden])
Date: 2016-03-09 06:43:19

> -----Original Message-----
> From: Boost [mailto:boost-bounces_at_[hidden]] On Behalf Of Klaim - Joël Lamotte
> Sent: 09 March 2016 10:53
> To: Boost Developers List
> Subject: Re: [boost] 32/64 library name conflict under Windows?
> 
> On 9 March 2016 at 10:35, Paul A. Bristow <pbristow_at_[hidden]> wrote:
> 
> >
> >
> > > -----Original Message-----
> > > From: Boost [mailto:boost-bounces_at_[hidden]] On Behalf Of Gavin
> > Lambert
> > > Sent: 08 March 2016 22:45
> > > To: boost_at_[hidden]
> > > Subject: Re: [boost] 32/64 library name conflict under Windows?
> > >
> > > On 8/03/2016 17:18, Rene Rivera wrote:
> > > > 1. Some people don't fancy auto-linking.
> > >
> > > I think the only people who don't fancy auto-linking are probably those
> > > who are building on Linux or multi-platform, and so can't make use of
> > > it.  Encourage the gcc/clang devs to add support for it. :)
> > >
> > > > A) Having file names with "32" *and* "64" on them?
> > >
> > > Yes, but rather than just 32 and 64 it should be the actual arch name.
> > > Libraries built for ARM should be readily distinguishable from those for
> > > x86.
> >
> > +1 for x86, x64, arm ...
> >
> > > In fact the option I would personally prefer would be to do both of
> > > these at once -- embed the arch into the library name, but also build it
> > > to an arch-named output directory.
> > >
> > > It's not unreasonable to have different library paths for different
> > > arches, and with auto-linking the difference in library names is not
> > > important when building -- but having different names is important when
> > > distributing them local with an application; imagine a case where both a
> > > 32-bit exe and a 64-bit exe are to be installed to the same folder.
> > > Currently this is not possible because the Boost DLLs will clash.
> > >
> > > Even where auto-linking is not used, it's just a matter of specifying
> > > the library name in the project file / makefile / whatever with a
> > > placeholder variable for the arch, or conditionally setting the list of
> > > libraries in the same fashion as the library search path.  It's not that
> > > hard.
> >
> > If some people want to split into arch-based folders /x86 /x64 /arm ...,
> > then can't they easily do this at library build time
> >
> >
> > http://www.boost.org/doc/libs/1_60_0/more/getting_started/windows.html#install-boost-build
> >
> > "To use a different directory pass the
> >   --stagedir=directory
> > option to b2."
> >
> > A few typical build command lines could be provided to help?

> If arch type is not somewhere by default (that is, boost distribution
> officially put these files somewhere clear
> and identifiable), it means that the tools can't rely on a specific path to
> find the right binaries.

Agreed - and the default should be to put everything in one folder, as now.

But those building their own libraries, can easy do differently what they want
(and take the consequences of other changes needed in consequence)?

Paul