On Fri, Nov 14, 2008 at 2:46 AM, Thomas Berg wrote:

On Thu, Nov 13, 2008 at 11:59 PM, Brian Dawn 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@lists.boost.org 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