Re: [Boost-users] Boost Static Linking Woes

Subject: Re: [Boost-users] Boost Static Linking Woes
From: Thomas Berg (merlin66b_at_[hidden])
Date: 2008-11-14 23:49:42

On Fri, Nov 14, 2008 at 2:46 AM, Thomas Berg <merlin66b_at_[hidden]> wrote:
> On Thu, Nov 13, 2008 at 11:59 PM, Brian Dawn <azan00_at_[hidden]> wrote:
>> Alright, I recompiled boost with runtime-link=static but I got the same
>> error.
>>
>>>> After doing this, I guess there is some "magic" preprocessor define
>> you need to specify in your project, so the boost config header
>> becomes aware of what boost variant you are using...
>>
>> I have looked for some sort of preprocessor definition for static builds,
>> but I couldn't seem to find any. Does anyone happen to know what this
>> is/could be?
>>
>>>> I believe the only exception to this is Boost.Python, but that has
>>>> special
>> requirements that make static linking much more tricky I believe.
>>
>> I actually am linking to Boost.Python, and Boost.Filesystem (both really
>> nice libraries). However I probably should have said earlier, but I receive
>> 2 "Mixing a dll boost library with a static runtime is a really bad idea..."
>> errors. I assume 1 is for python and the other for filesystem?
>>
>> Any help is appreciated, I really need these to be statically linked.
>>
>> Thanks everyone!
>> -Brian.
>>
>>
>> _______________________________________________
>> Boost-users mailing list
>> Boost-users_at_[hidden]
>> http://lists.boost.org/mailman/listinfo.cgi/boost-users
>>
>
>
> The "runtime-link=static" argument should give you libraries with
> names like "libboost_filesystem-vc90-mt-s-1_37.lib" on Windows, where
> the "-s-" denotes linking to the static C++ runtime. If you're linking
> manually, make sure you link to these libs.
>
> For the macros, I think it is sufficient to make sure you don't define
> the boost macro for dynamic linking. The compiler automatically
> defines macros (depending on /MD, /MT etc.) which boost uses to figure
> out the rest. If this is done correctly, you should not get the
> "mixing a dll boost library" message.
>
> However:
> If you are using boost python, that could be causing the problem.
> Boost python depends on python, which also depends on the C++ runtime.
> I suspect that if you check, there is no "-s-" version of the boost
> python library. It could be that boost python requires linking to the
> shared C++ runtime (because of python itself), and the boost headers
> may try to enforce that (hence the error message).
>
> I would not expect Python itself to support a complete static build on
> Windows. Did you build python yourself?
>
> One thing you should do (no matter what) is to download "Dependency
> Walker" and look at your executable. If msvcr90.dll (or whatever
> version you are using) is in the dependency list it is still linked to
> the shared C++ runtime. Remember, all 3rd party libraries you link in
> must also be built with /MT for this dependency to vanish.
>
> I would recommend that you look again at ways of distributing your
> application with the shared C++ runtime, the easiest is to have
> everything built with /MD. I think there are several ways of doing it,
> including having a copy of msvcr90.dll in a specially named
> subdirectory inside your application's directory. I could dig up the
> info again if you're interested...
>
> Cheers,
> Thomas
>

Ok, I just tried to build a complete boost python program myself now
(with VS2005), linking to the static C and C++ runtime only. This is
what I found out in my case:
- libboost_python-vc80-mt-s-1_37.lib does in fact get built (sorry I
missed that earlier, thought this variant was unavailable)
- You need to define BOOST_PYTHON_STATIC_LIB in your project
- Don't specify any other macros, compiling with /MT and linking to
LIBCMT.lib and LIBCPMT should be sufficient

My little test program compiles and runs fine in this case, I am not
able to reproduce your errors.

Dependency walker shows that the only dependency to the shared C
runtime is the one from python25.dll. I don't know the full
consequences of mixing C runtimes like this; there could be two
separate heaps, but I don't think this is a problem when using the
Python C API.

Cheers,
Thomas