Subject: Re: [boost] [1.58.0] Release candidates available
From: Klaim - JoÃ«l Lamotte (mjklaim_at_[hidden])
Date: 2015-04-06 11:48:43
On Mon, Apr 6, 2015 at 5:30 PM, Peter Dimov <lists_at_[hidden]> wrote:
> Beman Dawes wrote:
> Likewise, why isn't the default a 64-bit build on a 64-bit system?
> Because you may want the software you're developing to run on 32 bit OSes,
> which is still the most common use case on Windows.
> Ideally, you need the default on Windows to be to build both, but the
> address model is not encoded in the name, so that's not possible at
BTW, I pointed several times in the past that this cause issues when you
want to support both 32 and 64bit on windows
and use CMake (for example) because there is no default convention from
boost telling if the binaries at the default locations
are 32 or 64 bit. Therefore the FindBoost cmake module will make your
project link with whatever binaries found at the default location.
even if you are building a 32bit app and the boost lib/binaries files are
64bit. The error is caught at link-time which is very confusing at first.
Details were in a ticket: https://svn.boost.org/trac/boost/ticket/10141
There are workaraounds (I make cmake force use to specify where is the link
directory, assuming the 32 and 64 bit are not in the same directory,
which is already an annoying assumption) but it would help if boost would
set a simple and default way to locate either 64bit or 32 at least on
Half of my projects using boost are both 64 bit and 32 bit, some are
exclusively 64bit and some are forced to stay 32bit until some dependencies
all support at least windows and my users are both 32 and 64bit os users.
I think having the 32 or 64 in the name of the library files by default
would help setting a helpful convention.
There is just a need for a convention which clarify where is what and
assume that both versions could be available (Which is not the case
> Unsubscribe & other changes: http://lists.boost.org/
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk