[Boost-users] Boost Static Linking Woes
Brian Dawn
I current have the latest boost compiled with bjam, I have a complete build. I am also using MS Visual C++ 2008 express. So far everything works out perfectly, however when the compiled application was run on another computer I got a classic "This application has failed to start because its side-by-side configuration is incorrect." error. So instead of generating a multithreaded DLL I changed it to just multithreaded.
However I then got this error message "Mixing a dll boost library with a static runtime is a really bad idea...". So it seems autolink wasn't finding my libraries. In order to get around this I then disabled the boost autolink feature and linked to the static libraries manually. The application was then able to compile correctly but I then received a runtime error complaining about a corrupt heap, my code ran just fine before.
Is there any way I can get around this? I would like my application to be multithreaded rather than multithreaded DLL to avoid the side-by-side configuration error when distributing my exe.
Thanks, Brian.
Cory Nelson
>
> Is there any way I can get around this? I would like my application to be
> multithreaded rather than multithreaded DLL to avoid the side-by-side
> configuration error when distributing my exe.
>
Your side-by-side error is probably due to the VC++ runtime not being
installed, or your exe not having a manifest to load it.
--
Cory Nelson
_______________________________________________
Boost-users mailing list
Boost...@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/boost-users
Vladimir Prus
> Hello everyone!
> I current have the latest boost compiled with bjam, I have a complete build. I am also using MS
> Visual C++ 2008 express. So far everything works out perfectly, however when the compiled
> application was run on another computer I got a classic "This application has failed to start
> because its side-by-side configuration is incorrect." error. So instead of generating a
> multithreaded DLL I changed it to just multithreaded.
>
> However I then got this error message "Mixing a dll boost library with a static runtime is a
> really bad idea...". So it seems autolink wasn't finding my libraries.
If the error message say:
"Mixing a dll boost library with a static runtime is a really bad idea..."
then your conclusion that autolink is not finding your libraries appears to be not based on
anything. Did you read, and understood the error?
> In order to get around this
> I then disabled the boost autolink feature and linked to the static libraries manually. The
> application was then able to compile correctly but I then received a runtime error complaining
> about a corrupt heap, my code ran just fine before.
This seems exactly what the error message what trying to prevent ;-)
>
> Is there any way I can get around this? I would like my application to be multithreaded rather
> than multithreaded DLL
I don't know how 'application' can be a 'DLL' at the same time. If you want your application to
be fully static, you need to use static Boost libraries -- and make sure that neither
BOOST_ALL_DYN_LINK, or BOOST_<library>_DYN_LINK macros are not set. I assume your application
explicit links to libboost_whatever.lib libraries, not boost_whatever.lib?
- Volodya
John Maddock
>> However I then got this error message "Mixing a dll boost library
>> with a static runtime is a really bad idea...". So it seems autolink
>> wasn't finding my libraries.
That suggests a build problem somewhere: do you still have BOOST_ALL_DYN_LIB
defined or something?
>> In order to get around this I then
>> disabled the boost autolink feature and linked to the static
>> libraries manually. The application was then able to compile
>> correctly but I then received a runtime error complaining about a
>> corrupt heap, my code ran just fine before.
Sounds like you're mixing different runtime library versions - your linker
should have emitted warnings or errors about that, either way it's a really
bad idea, and the very problem that auto-linking was intended to solve!
HTH, John.
Schau,Sönke HG-Dir ae-se
Maybe you try to run a debug version on the other computer?
There is no redistributable debug runtime for vc, so every attempt to start a program compiled with debug results in such message.
Sönke
Brian Dawn
I am sorry, I did not explain my situation as well as I should have. I have a complete build of boost installed so I had assumed it created static libraries alongside dynamic ones. When I received the "Mixing a dll boost library with a static runtime is a really bad idea..." message I had assumed autolink was to blame because I had assumed it would recognize the static install and thus search for the static libraries. When I disabled autolink I directly linked to "libboost_whatever.lib" as those are the static libraries correct? However that's when I received the heap corruption.
As for the macros... I checked my user & config files, and BOOST_ALL_DYN_LINK was commented out.
>> That suggests a build problem somewhere: do you still have BOOST_ALL_DYN_LIB
defined or something?
Does boost complete build both static and dynamic libraries? Because maybe that is my problem.
I appreciate everyone's help.
Thanks,
-Brian.
Thomas Berg
> Boost-users mailing list
> Boost...@lists.boost.org
> http://lists.boost.org/mailman/listinfo.cgi/boost-users
>
The boost libraries are usually linked against the shared C++ runtime
(compiled with /MD), unless you explicitly specify something else with
bjam. Your application should be linked to the same version of the C++
runtime.
If you really want to link your application against the static runtime
(compile with /MT) I guess you have to build boost with this flag too.
IIRC it is done by specifying runtime-link=static to bjam when
building boost. Did you do this yet?
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...
Hope this helps,
Thomas
John Maddock
>>>> That suggests a build problem somewhere: do you still have
>>>> BOOST_ALL_DYN_LIB
>> defined or something?
>>
>> By still, do you mean that it is defined by default? Because I had
>> never undefined it.
No, I mean you won't see that message from the auto-linking code unless:
* You are linking to a static runtime, *and*
* You have either BOOST_ALL_DYN_LINK or BOOST_<libname>_DYN_LINK defined
somewhere.
I believe the only exception to this is Boost.Python, but that has special
requirements that make static linking much more tricky I believe.
>> Does boost complete build both static and dynamic libraries? Because
>> maybe that is my problem.
If you built with "--build-type=complete" then yes.
The static libs all start with the prefix "lib", and the dll import libs do
not.
HTH, John.
Brian Dawn
>> 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 believe the only exception to this is Boost.Python, but that has special
requirements that make static linking much more tricky I believe.
Any help is appreciated, I really need these to be statically linked.
Thanks everyone!
-Brian.
Thomas Berg
> Boost-users mailing list
> Boost...@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
Thomas Berg
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.