Build 32 and 64 bit libraries for boost at sametime?

Question

Will the option "--address-model=32,64" build both 32 and 64 libraries or do you have to do two separate builds?

**For those of you compiling for i386 Mac OS** and stumbled here, and it didn't work, then you were on the verge of committing suicide (like me), add this flag, too: `architecture=x86` — Mazyod, Jun 19 '13 at 00:41
I'm having a similar question. I can build boost 32 and 64 bit (the 32_64 suggestion in the answer below does NOT work on windows with version 1.57.0) and store them in different lib directories, but when referencing those libs, what is the best or suggested approach to organizing them? I want to be able to build 32 bit and 64 projects without having to swap between environment variables (e.g. when using cmake) — StarShine, Apr 02 '15 at 12:51

score 23 · Accepted Answer · answered Feb 02 '12 at 05:22

23

Doing:

b2 address-model=32,64

Or..

b2 address-model=32,64,32_64

Work and produces, depending on toolset and platform support, both 32 and 64 bit targets in the first case. And 32, 64, and 32+64 universal targets (most likely only on OSX using the darwin toolset. And by "works" I mean that I just tried it with my Boost library on OSX with the darwin toolset. Hence I suspect you have your syntax wrong, i.e. don't use "--name=values" as they are not options, but instead use "name=values" are the are requirement specifications.

answered Feb 02 '12 at 05:22

GrafikRobot

3,020
1
20
21

2

Thanks for the syntax clarification! Maybe I'm being picky but shouldnt b2 be giving an error (warning at minimum) when the syntax is incorrect? I guess the moral of the story is be careful with b2!! – PopcornKing Feb 03 '12 at 05:29
It's not actually easy, from the POV of the b2 implementation, that the syntax is incorrect. It sees a correctly syntaxed option (anything that starts with "-", that it doesn't recognize, which is passed to the Jamfiles. Which all look at the option, in a modular way, and decide they don't handle. Hence there is no place where it can decide that the option is not valid. I.e. it just ends up being ignored. Which is an effect of the b2 CLI not being a closed syntax set. – GrafikRobot Feb 03 '12 at 13:31
20

I think you will have a problem with this when it comes to getting the libraries out because unfortunately the 32 bit and 64 bit libraries have identical names. You need to run b2 twice. One time with, for example, "--stagedir=stage32 address-model=32" and one time with "--stagedir=stage64 address-model=64". – mheyman Mar 13 '13 at 16:49
1

Where is the 32_64 option documented? I can't find it anywhere (and I don't believe it is actually possible to store both of them in the same lib/dll on windows) – StarShine Apr 02 '15 at 12:52
1

@StarShine It's mentioned in the [source](https://github.com/boostorg/build/blob/develop/src/tools/builtin.jam#L242), and in the [darwin toolset comments](http://www.boost.org/build/doc/html/bbv2/reference/tools.html#bbv2.reference.tools.compiler.darwin). And like I said in my answer.. "most likely only on OSX using the darwin toolset." – GrafikRobot Jun 16 '15 at 03:28

score 11 · Answer 2 · answered Feb 01 '12 at 21:33

11

The documentation states (emphasis mine):

"Explicitly request either 32-bit or 64-bit code generation."

Note that it doesn't say "one or more of" or "at least one of", it says either ... or, which implies XOR in my reading of it and your experience matches that.

The comma in the list of allowed values is just to separate the two items in the set of allowed values.

answered Feb 01 '12 at 21:33

Flexo

87,323
22
191
272

The documentation also states: "The comma has special meaning only if the feature has a fixed set of values, so bjam include=static,shared is not treated specially." 32 and 64 seem fixed to me for address-model. Thanks for response. – PopcornKing Feb 01 '12 at 21:42
1

@PopcornKing - I think the "either .. or" comment on the specific flag supersedes any general remarks that otherwise apply – Flexo Feb 01 '12 at 21:48

score 6 · Answer 3 · answered Apr 02 '15 at 14:01

I ended up doing the following:

Store the 32 lib/dll builds in a separate folder called /lib32
Store the 64 lib/dll builds in a seaprate folder called /lib64

Both are preferably in a search path that boost is already checking, such as stage or the installation folder.

Then I added this block right after the search paths are assembled under the header ( the FindBoost.cmake file to edit is under share/cmake-3.1/Modules/ folder in your CMake installation folder )

Begin finding boost libraries

...

if(Boost_LIBRARY_DIR)

...

endif()

#generate 32 and 64 bit paths
if(WIN32)
    if(CMAKE_CL_64)
        #message("Finding BOOST on windows platform (64 bit)")
        SET(BOOST_libdir_suffix_gen "64")
    else()
        #message("Finding BOOST on windows platform (32 bit)")
        SET(BOOST_libdir_suffix_gen "32")
    endif()

    list(APPEND _boost_LIBRARY_SEARCH_DIRS_PLATFORMS "")
    foreach(SEARCH_DIR_NOPLATFORM ${_boost_LIBRARY_SEARCH_DIRS})
        list(APPEND _boost_LIBRARY_SEARCH_DIRS_PLATFORMS ${SEARCH_DIR_NOPLATFORM}${BOOST_libdir_suffix_gen})        
    endforeach()
    foreach(SEARCH_DIR_PLATFORM ${_boost_LIBRARY_SEARCH_DIRS_PLATFORMS})
         list (APPEND _boost_LIBRARY_SEARCH_DIRS ${SEARCH_DIR_PLATFORM})
    endforeach()
else()
    # no generation required (?)
endif()

It will re-append all existing lib directories to the boost search path for libraries, suffixed with a 64 or 32 bit extension tag. This selects the correct target libs for linking, and you can safely regenerate any other dependent cmake library (like CGAL) for a 32 or 64 target build without resetting the boost dependency path.

Build 32 and 64 bit libraries for boost at sametime?

3 Answers3