Boost build issue on Windows/MinGW

[tristen_e@…]

bjam link=static --toolset=gcc

If I build boost static libraries on windows with the intention of using them with the GCC toolset, the resulting libraries are created with a .lib extension:

libboost_date_time-mgw34-mt-1_35.lib libboost_filesystem-mgw34-mt-1_35.lib libboost_graph-mgw34-mt-1_35.lib libboost_iostreams-mgw34-mt-1_35.lib libboost_prg_exec_monitor-mgw34-mt-1_35.lib libboost_program_options-mgw34-mt-1_35.lib libboost_regex-mgw34-mt-1_35.lib libboost_serialization-mgw34-mt-1_35.lib libboost_signals-mgw34-mt-1_35.lib libboost_system-mgw34-mt-1_35.lib libboost_test_exec_monitor-mgw34-mt-1_35.lib libboost_thread-mgw34-mt-1_35.lib libboost_unit_test_framework-mgw34-mt-1_35.lib libboost_wave-mgw34-mt-1_35.lib

Subsequently, after compiling my code using these libraries, I get a run-time error saying the relevant DLL wasn't found.

However, if I rename all of the boost libraries from .lib files to .a files and compile again, the run-time errors go away and the program runs fine. The executable size increases approximately by the size of the static library too.

I feel the solution to this problem is to have BJAM generate the set of static libraries with an extension of .a instead of .lib under windows if the GCC toolset was specified.

ie:

bjam link=static --toolset=gcc

should result in the following files on Windows:

libboost_date_time-mgw34-mt-1_35.a libboost_filesystem-mgw34-mt-1_35.a libboost_graph-mgw34-mt-1_35.a libboost_iostreams-mgw34-mt-1_35.a libboost_prg_exec_monitor-mgw34-mt-1_35.a libboost_program_options-mgw34-mt-1_35.a libboost_regex-mgw34-mt-1_35.a libboost_serialization-mgw34-mt-1_35.a libboost_signals-mgw34-mt-1_35.a libboost_system-mgw34-mt-1_35.a libboost_test_exec_monitor-mgw34-mt-1_35.a libboost_thread-mgw34-mt-1_35.a libboost_unit_test_framework-mgw34-mt-1_35.a libboost_wave-mgw34-mt-1_35.a

Regards Tristen

[Vladimir Prus]

I don't understand your "I get a run-time error saying the relevant DLL wasn't found." statement. What is "relevant DLL" and how any DLL can be relevant when doing static linking and that is the actual error.

[tristen_e@…]

Hi Vlad,

Sorry to take so long in responding - I only just found the email.

To answer your question: I'm as confused as you. I politely asked GCC to link statically to the boost libs; linking completes successfully (ie: with no errors); it's only at run-time that the executable complains rather rudely about not being able to find the boost dlls.

Since I typed the issue in all those months ago I think the problem is more related to the fact that I'm using MinGW in a Cygwin environment. Hence maybe that's why the linker in my environment is treating .lib files as if they were .dll files.

So whatever the reason, renaming the .lib files to .a files works, ie: the compiler/linker makes an executable statically linked using the .a files.

And finally, if my suspicions are correct, then this isn't a problem at all, ie: how can bjam know if my intentions are to use the Windows boost libraries from Cygwin, unless of course you guys are willing to add a --toolset=mingw-via-cygwin flag to bjam ;)

No I wouldn't either :)

[Vladimir Prus]

Should be done with other mingw fixups for 1.42

[Vladimir Prus]

Actually fixed now.