Boost logo

Boost :

Subject: Re: [boost] Default variants on windows
From: Thomas Klimpel (Thomas.Klimpel_at_[hidden])
Date: 2009-04-11 12:53:48


> > I understood it differently: Autolink doesn't default to anything,
> > but simply does what is specified by the linker options. If my
> > understanding is correct, the statement "Autolink defaults to..." is at least misleading.
>
>
> Either BOOST_<library name>_DYN_LINK or BOOST_ALL_DYN_LINK
> must be defined to get dynamic linking. No macro means static linking.

I thought afterwards that writing "linker options" was not a good idea, because it is macros like _DEBUG, and _DYN_LINK that control the behavior. Still I think that these macros have more influence than just changing the behavior of autolink. So even if the autolink feature would be removed, the macros would still be there (at least that's what I think, I may be wrong).

So I still think the statement "Autolink defaults to..." is at least misleading. (It's called "auto...", so no need to "default" to anything.)

My main point was that a "default" solution won't really work for Windows, so documentation of the most frequently occurring issues is needed. Just as an example, I now specify <define>_SECURE_SCL=0 on the command invoking bjam when building the release variant. However, I can't tell whether this is the way I'm supposed to solve this issue. When the issue first occurred for me, all I could find was that I should define _SECURE_SCL=0, but no indication of how to define it (it was with boost-build-v1). I ended up modifying the jamfiles themselves, but at least it worked... And before I could even do that, I first had to figure out via debugging that the crashes I was observing were due to an ABI issue caused by _SECURE_SCL.

I'm not against a "default" solution, but against pretending that something just works out of the box that simply doesn't.

Regards,
Thomas


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