Re: [boost] Boost Jam question: how to set "features"?

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2001-11-09 10:32:43

----- Original Message -----
From: "Steve Anichini" <sanichin_at_[hidden]>

> I can't think of any reason a library should require linking to the DLL C
> runtime instead of the LIB C runtime.

I can only think of one: if a dynamic library allocates resources (e.g.
memory) by calling into the runtime library it's statically linked with, but
passes the resource off to another dynamic library which is separately
statically linked to the runtime, the two libraries may be dealing with
different heaps. This can cause memory management havoc, or so I've heard.

...and in fact, after testing it, it appears that I'm right. All of the
python tests that use multiple python extension modules at once crash if
they link to the runtime statically.

> For some applications, linking to the static version of the runtime makes
> more sense. For example, with static linking one doesn't have to
> redistribute the C runtime (msvcrt.dll) with your app. Even though some
> version of msvcrt.dll ships with all Win9x and WinNT systems, it's not
> necessarily the version you need if you need one with a bug fix from one
of
> the VC6 service packs. Also, if you are using MFC and linking to the DLL,
> you have to distribute the MFC DLL as well for the same reason.
>
> Yes, static linking produced larger executables. But it also is an easy
path
> to know exactly what version of the C-runtime and MFC you are using.
> Otherwise you can find yourself in DLL hell, and supported mechanisms to
> cope with multiple DLL versions didn't really exist until Windows 98
Second
> Edition/Win2K:
>
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/sbscs/sideb
> yside_2l2r.asp
> Windows XP introduces a better mechanism, but not everyone lives in a
world
> where they can ignore NT 4, or Pre-98 Second Edition Win9x.
>
> If you still don't believe me, try writing a production-quality installer
> that deals with DLL/COM redirection and you will realize the pain that it
> can cause! It's a very difficult thing to get right.

Thanks for the education.

> I don't think boost should be imposing this choice on the user unless it
> absolutely has to. (Yes I know you technically can mix libraries compiled
> with one runtime with another using /IGNORELIB, but I find that option
> distasteful.) Just because the pyhton stuff requires the dynamic runtime
> doesn't mean the rest of boost should be forced to - I'm not even using
the
> python stuff. I just want to build boost! :)

OK; for the time being you can just go to the libs/regex/build and
libs/thread/build directories and invoke "jam -sBOOST_ROOT=../../.." in
each. I'll see what I can do about the dynamic link requirements on the
python library.

> If the python stuff absolutely must use the DLL runtime, can we modify the
> jamfiles so that:
> a) no matter what the user specifies, libboost_python builds with the DLL
> runtime.
> or
> b) if you specify the static runtime, libbost_python is skipped by the
> build with some appropriate warning.
> or
> c) make the python stuff work with the static C runtime.

Yeah; I'm not sure which of those is better. Warnings tend to get lost in
the large quantity of output generated by any command-line build tool.

Hmm... oh, there /is/ a solution!

jam -sDEFAULT_BUILD="release <runtime-link>static" will work.

John maddock has specified <runtime-link>dynamic in the default-BUILD
section of his regex library specification, which will override your
command-line setting. But, it seems to me, he didn't need to do that, since
<runtime-link>dynamic is the default.

I'll try building that way and running the regex regression tests.
Okay, that seemed to work. So, I'll check in the new regex Jamfile. Why
don't you try the command-line suggested above?

-Dave