passing compiler flags to boost libraries (such as Thread) which require compilation

Question

So I know that the boost libraries are primarily header-only but there are a few which require compilation, for example Boost.Thread. In Darwin, how do I compile these and pass the -m32 flag so they can be compiled into a 32-bit (i386) binary? There's this Jamroot thing which I've never heard of and I am not sure at all where to start.

Clarification: I'm not asking how to compile a program with -m32 flag and use the boost libraries. I'm asking how to compile the Boost libraries themselves with the -m32 flag.

Unicorn

boost.org/doc/libs/1_47_0/more/getting_started/… – Tamishatamma

-1 for not reading the official introductory documentation, sorry. – Motch

@ArunMu, yes I know, I've seen that page. It doesn't answer my question. There are a few flags you can pass to b2, but none of them allow you to change the architecture. I tried looking at the Jamroot file but I couldn't see anywhere to specify compiler flags like this. – Unicorn

@phresnel if you're talking about the documentation that ArunMu posted, that definitely doesn't answer my question at all. – Unicorn

So, have you read any documentation? Like on how to set configuration parameters for compiling boost? Have you looked at Jam documentation already? Have you looked whether someone else already did the job for you? If you had read some documentation, you'd already know that Jamroot corresponds to the boost-build-system. Note that the vote-down button specifically say "does not show any research effort", which is exactly the case here: You don't show any research effort in your question, sorry. – Motch

@phresnel whatever, man. I'm reading through this giant reference manual [boost.org/doc/libs/1_47_0/doc/html/bbv2.html] right now on Boost.Build trying to understand how this build system works. I finally did find a compiler flag that seems like it might do what I want, but now it doesn't want to rebuild -- so I have to figure out how to clean. Anyway this is definitely not introductory documentation. But hey whatever, if you want to vote me down and then flame me, what can I do about it? Nothing. – Unicorn

That's not flaming, "man". Scroll your cursor over the vote-down button and see yourself. – Motch

@phresnel Well, the reason I'm sore about your downvote is that I really did investigate this before posting my question, and I really did hit a wall -- mostly because I thought that "b2" was just some kind of simple script that was invoking a makefile or cmake or something. I had no idea that there was a whole elaborate special build system for boost that I would have to learn. All your downvote is really doing is now making me paranoid that every time I post something I have to list all the reading I've already done just in case somebody decides that I don't "sound like" I've RTFM. – Unicorn

You missed the "show" in "does not show any research effort". You should clarify what you have tried (generally, so that we don't make the same mistakes or false attempts) and to demonstrate that you are not unwilling to do anything yourself. We don't have working glass spheres, and if you don't show what you've done, we may just assume that you didn't do anything. I removed the downvote. In general, SO is not a RTFM community, iff you show effort on your own. Help us to help you, and show that you are doing so ;) – Motch

@phresnel well thanks. I guess I'm over it now, but Boost.Build made me really cranky. Thanks for being understanding. It was one of those things where the only reason I was using Boost.Build is because it was required by A and the only reason I was using A was because it was required by B and the only reason... etc etc. – Unicorn

Boost.Build is a major pain in the backside, especially because it's both under- and overdocumented at the same time, and because it's been a moving target for years now. Things that worked fine for one version required a different approach in the next, and yet a different one in the version thereafter. I feel your pain. – Crispation

You guys are too mean. Boost's build document is not easy to read. – Phantom

Answer 1

To specify what architecture to compile for, specify the architecture feature when invoking b2.

To specify compiler options that don't already have built-in features, specify the cxxflags feature when invoking b2.

To specify linker options that don't already have built-in features, specify the linkflags feature when invoking b2.

All of these are listed in the Boost.Build docs.

Inserted

Thanks. The fact that I finally figured out that b2 and bjam are the same thing really helped here -- I used diff to confirm this. Why have two identical versions of the executable, one of which is almost completely undocumented (b2)? That makes no sense to me. The official docs were really hard to parse for me -- this made much more sense: highscore.de/cpp/boostbuild. Thanks for your help also. – Unicorn

@Unicorn : 'b2' is the new official name for 'bjam'. I.e., they are one and the same, but the name 'bjam' is now obsolete. – Inserted

The link about the boost build docs leads to a 404 now – Delamination

Answer 2

From what I understand, and if I read the documentation correctly, the way to build a particular architecture of boost is with the "address-model=xx" option for b2.

EXAMPLES:

b2 install toolSET=msvc-9.0 link=shared variant=release address-model=64

or

b2 install toolSET=msvc-9.0 link=shared variant=release address-model=32

Hope that helps.

Regards,

-RMWChaos

EDIT: Found another SO Thread providing the same answer here.

Handel