Subject: Re: [boost] 32/64 library name conflict under Windows?
From: Paul A. Bristow (pbristow_at_[hidden])
Date: 2016-03-08 05:45:51
> -----Original Message-----
> From: Boost [mailto:boost-bounces_at_[hidden]] On Behalf Of Rene Rivera
> Sent: 08 March 2016 04:19
> To: boost_at_[hidden]
> Subject: Re: [boost] 32/64 library name conflict under Windows?
> On Fri, Mar 4, 2016 at 12:31 PM, Peter Dimov <lists_at_[hidden]> wrote:
> > I remember that we discussed this problem before:
> > C:\Projects\boost-git\boost>b2 --with-system toolset=msvc-10.0
> > address-model=32,64
> > [...]
> > error: Name clash for '<pstage\lib>libboost_system-vc100-mt-gd-1_61.lib'
> > error:
> > error: Tried to build the target twice, with property sets having
> > error: these incompatible properties:
> > error:
> > error: - <address-model>32
> > error: - <address-model>64
> > error:
> > error: Please make sure to have consistent requirements for these
> > error: properties everywhere in your project, especially for install
> > error: targets.
> > but don't remember what we concluded. Will we support building both 32 and
> > 64 bit libraries under Windows? At present if I want to have an IDE project
> > that has both Win32 and x64 configurations I need to build the 32 bit
> > libraries, move them out of stage/lib somewhere, then build the 64 bit
> > libraries, then move them out of stage/lib to somewhere else, and set my
> > library directories in the IDE accordingly.
> > It would be much more convenient if 32/64 were encoded into the name, so
> > that I can leave my library path to point at stage/lib and rely on autolink
> > to choose the right .lib file automatically, like it works today for the
> > other options (debug/release, static/dynamic runtime).
> 1. Some people don't fancy auto-linking.
Excellent (when it works - almost always).
> 2. People responding with "+N".. Which of the following would you prefer?
> And give rationale for your preference, and optionally give rationales for
> not preferring others:
> A) Having file names with "32" *and* "64" on them?
Explicit is good.
Follows current scheme of having different unique names for different variants.
Once started unique names, we should continue.
> B) Having current names indicate 32 and adding "64" to file names otherwise?
> C) Having current names indicate the "default" system address-model and add
> "32" or "64" to indicate the non-default?
> D) Having the current names and placing 32 bit address-model variants in
> "stage/lib32" and 64 bit in "stage/lib64"? (Equivalently for install location)
Having two files with same name in different folders is less explicit than two different filenames.
> E) Having the current names and placing 32 bit address-model variants in
> "stage/lib" and 64 bit in "stage/lib64"? (Equivalently for install location)
Make be less trouble short term, but less clear when 64 becomes the default?
(and what about 128-bit ;-)
> F) Having the current names and placing the "default" system address-model
> variants in "stage/lib" and the non-default in "stage/lib32" or
> "stage/lib64"? (Equivalently for install location)
KISS (https://en.wikipedia.org/wiki/KISS_principle is *my* default position).
So I favour option A.
--- Paul A. Bristow Prizet Farmhouse Kendal UK LA8 8AB +44 (0) 1539 561830
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk