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

From: Steve Anichini (sanichin_at_[hidden])
Date: 2001-11-09 09:44:58

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

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.

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! :)

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.

-steve

> -----Original Message-----
> From: David Abrahams [mailto:david.abrahams_at_[hidden]]
> Sent: Friday, November 09, 2001 6:35 AM
> To: boost_at_[hidden]
> Subject: Re: [boost] Boost Jam question: how to set "features"?
>
>
>
> ----- Original Message -----
> From: "Steve Anichini" <sanichin_at_[hidden]>
>
>
> > ah, thank you.
> >
> > but now I get a build error:
> >
> F:\develop\projects\external\boost_1_25_1>f:\develop\projects\buil
> dtools\mai
> >
> n\bin\jam -sBOOST_ROOT=. -sTOOLS="msvc-stlport"
> -sSTLPORT_4.5_PATH=f:\develo
> > p\projects\external\stlport-4.5 -sBUILD="<runtime-link>static"
> > Error: <libs!python!build>libboost_python: target requirements conflict
> for
> > requ
> > ested build { <runtime-link>dynamic <target-type>LIB
> <runtime-link>static }
> >
> > if i substitute -sBUILD="<runtime-link>dynamic" it works.
>
> That's because linking to the runtime library dynamically is in the target
> requirements for libboost_python (see the declaration of PYTHON_PROPERTIES
> at the top of the libs/python/build/Jamfile. I'm fairly sure that it
> wouldn't work if you changed that. Even if I'm wrong, every python module
> would be much larger due to the statically linked runtime library.
>
> If you really want to try this, replace the last line of the
> libboost_python
> requirements:
>
> lib libboost_python : ../src/$(CPP_SOURCES).cpp
>     # requirements
>     : $(BOOST_PYTHON_INCLUDES)
>     <shared-linkable>true
>     $(PYTHON_PROPERTIES) ; # <=== this line
>
> with the following:
>
>         <gcc><*><define>SIZEOF_LONG=4
>         <gcc><*><define>USE_DL_IMPORT ;
>
> let me know if it works out for you,
>
> Dave
>
>
> Info: http://www.boost.org  Unsubscribe:
<mailto:boost-unsubscribe_at_[hidden]>

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/