From: Steve Anichini (sanichin_at_[hidden])
Date: 2001-11-09 10:41:38
thanks! i'll try the workaround later today.
> -----Original Message-----
> From: David Abrahams [mailto:david.abrahams_at_[hidden]]
> Sent: Friday, November 09, 2001 9:28 AM
> To: boost_at_[hidden]
> Subject: Re: [boost] Boost Jam question: how to set "features"?
> ----- 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
> > 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
> > 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
> > Edition/Win2K:
> Windows XP introduces a better mechanism, but not everyone lives in a
> 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
> 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
> 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
> b) if you specify the static runtime, libbost_python is skipped by the
> build with some appropriate warning.
> 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="<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.
Info: http://www.boost.org Unsubscribe:
Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk