Subject: [Boost-bugs] [Boost C++ Libraries] #10141: Missing convention for 32/64 binaries identification prevents tools detection.
From: Boost C++ Libraries (noreply_at_[hidden])
Date: 2014-06-21 16:38:07
#10141: Missing convention for 32/64 binaries identification prevents tools
Reporter: mjklaim@â¦ | Owner: vladimir_prus
Type: Bugs | Status: new
Milestone: To Be Determined | Component: build
Version: Boost 1.55.0 | Severity: Problem
This is a summary of the issue I reported in this discussion: (add missing
url protocol here)groups.google.com/forum/#!topic/boost-developers-
Summary of the issue:
1. The problem occurs when you want to setup projects on Windows which
use Boost and CMake and should be built for both 32 and 64 bit targets.
2. The issue is that CMake's module FindBoost have no way to identify a
default 32 or 64 bit library directory (or binaries), because Boost don't
define a default or conventional way to identify which is which.
3. FindBoost CMake module rely on the Boost_DIR variable (environment or
not) to know where to find the ./lib directory which contain the necessary
binaries. However, there is no convention as to what this directory
contain so it could be 32 or 64 bit. If we generate a 64bit project
through CMake and we have only the 32bit binaries in this directory, the
issue will only be detected at link time. I first identified this issue by
hitting this problem, then hitting it again several time each time I tried
to setup a small project using CMake and Boost on Windows.
4. There are several quick fixes to this:
a) Have your project's CMake scripts require/force the user to specify
the BOOST_LIBRARYDIR variable so that it is clear which binary directory
will be used for the generated project files. This mean that you have to
put this the hack in any new project you create (that uses CMake, Boost
and should be built with both 32 and 64 bit) AND additionally even for one
unique project you have to set BOOST_LIBRARYDIR manually each time you
need to re-generate the project files. A lot of repetition could be
avoided by fixing this issue.
b) Have a modified FindBoost module which knows where to find your
32 and 64 bit binaries of Boost. It would rely on a convention
specific to your (or your company context) which mean that it's not a
general solution at all.
c) Have separate Boost root directories for each binary kinds and
change the Boost_DIR value each time you change project. This don't help
when you work on several projects at the same time.
There are other ways to get around the issue. I personally use the a) but
I'm not happy with the time it makes me lose regularly.
5. Rob Stewart pointed that there are 2 directories of Program Files
which are 32 and 64 bis so depending on your install target there could be
a detection of which one to use. However FindBoost rely on only one root
address for the place to find Boost library (both sources and binaries) so
having both 32 and 64 bit versions of boost installed cannot be specified
through only one Boost_DIR variable. Also, only the BOOST_LIBRARYDIR
variable changes between the different kinds of libraries.
In any way, if you use your own version of Boost and build it yourself,
the simple way to make it available to CMake is to specify Boost_DIR and
let it find the libraries. Currently this work from scratch only if your
CMake generated projects files are always of the same platform than the
platform of the default Boost build install (32 bit...). Otherwise you
have to modify your project's CMake script in a non-general way. Things
get even funnier when you are working with more than one version of Boost,
because of different dependency requirements in your projects.
1. Define a default directory for both 32 and 64 bit so that there is a
basic convention for tools to find them automatically.
2. Define a default prefix or suffix to differentiate the different
binaries (32 and 64 bit).
I understand that there could be issues on non-Windows platforms if the
names are not uniform so I'm suggesting these potential solutions only for
I guess there could be other solutions but at the moment I don't see any
that would be simple enough.
Unfortunately I cannot provide any patch to either boost or CMake because
in my opinion a convention for identifying these binaries have to be
defined first by the Boost (committee?) members before doing any
-- Ticket URL: <https://svn.boost.org/trac/boost/ticket/10141> Boost C++ Libraries <http://www.boost.org/> Boost provides free peer-reviewed portable C++ source libraries.
This archive was generated by hypermail 2.1.7 : 2017-02-16 18:50:16 UTC