Boost logo

Boost :

Subject: Re: [boost] 32/64 library name conflict under Windows?
From: Klaim - Joël Lamotte (mjklaim_at_[hidden])
Date: 2016-03-09 15:06:18


On 9 March 2016 at 20:49, Rob Stewart <rstewart_at_[hidden]> wrote:

> On March 9, 2016 5:53:08 AM EST, "Klaim - Joël Lamotte" <mjklaim_at_[hidden]>
> wrote:
> >On 9 March 2016 at 10:35, Paul A. Bristow <pbristow_at_[hidden]>
> >wrote:
> >
> >> 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.
>
> What tools rely on Boost to put libraries in some official location?
>
>
CMake's FindBoost.cmake module which is distributed with CMake for example.

Several times in the past I built a boost version with default location (or
got the binary distribution)
and setup my project using CMake to use Boost. Then I get link time errors
because I was compiling in 32bit
(I use both 32 and 64bits in most of my projects) and Boost only existed in
the native platform's architecture version.
To help me remember about this issue, I setup a specific CMake macro in all
my projects (which could be
by someone else than me) to force the user at cmake's configure time to
specify which binaries to use (I use separaet
folders at the moment to provide the lib directory path to FindBoost.cmake).

> ___
> Rob
>
> (Sent from my portable computation engine)
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk