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