https://svn.boost.org/trac10/ticket/10141 <p> This is a summary of the issue I reported in this discussion: (add missing url protocol here)groups.google.com/forum/#!topic/boost-developers-archive/JhIRbtl4_DA </p> <p> Summary of the issue: </p> <ol><li>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. </li></ol><ol start="2"><li>The issue is that CMake's module <a class="missing wiki">FindBoost</a> 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. </li></ol><ol start="3"><li><a class="missing wiki">FindBoost</a> 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. </li></ol><ol start="4"><li>There are several quick fixes to this: </li></ol><blockquote> <blockquote> <p> 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. </p> </blockquote> </blockquote> <blockquote> <blockquote> <p> b) Have a modified <a class="missing wiki">FindBoost</a> 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. </p> </blockquote> </blockquote> <blockquote> <blockquote> <p> 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. </p> </blockquote> </blockquote> <p> 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. </p> <ol start="5"><li>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 <a class="missing wiki">FindBoost</a> 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. </li></ol><p> 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. </p> <p> Suggestions (exclusive): </p> <ol><li>Define a default directory for both 32 and 64 bit so that there is a basic convention for tools to find them automatically. </li><li>Define a default prefix or suffix to differentiate the different binaries (32 and 64 bit). </li></ol><p> 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 Windows. </p> <p> 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 implementation. </p> en-us /htdocs/site/boost.png https://svn.boost.org/trac10/ticket/10141 Trac 1.4.3 Mateusz Loskot Thu, 23 Apr 2015 19:17:13 GMT https://svn.boost.org/trac10/ticket/10141#comment:1 https://svn.boost.org/trac10/ticket/10141#comment:1 <ul> <li><strong>cc</strong> <span class="trac-author">mateusz@…</span> added </li> </ul> Ticket Steven Watanabe Mon, 22 Jan 2018 23:46:36 GMT https://svn.boost.org/trac10/ticket/10141#comment:2 https://svn.boost.org/trac10/ticket/10141#comment:2 <ul> <li><strong>status</strong> <span class="trac-field-old">new</span> → <span class="trac-field-new">closed</span> </li> <li><strong>resolution</strong> → <span class="trac-field-new">fixed</span> </li> </ul> <p> The architecture and address-model are encoded in the library names as of 1.66. </p> Ticket