Static linking with libwinpthread

Question

I try to build program with static linked toolchain libraries. I pass:

LDFLAGS="-Wl,-Bstatic -lwinpthread -Wl,-Bdynamic -static-libgcc -static-libstdc++"

but program linked with shared libwinpthread-1.dll.

What I doing wrong?

Only way when I got static linked libwinpthreads is pass -static to LDFLAGS. But it break build programs with plugin system.

I use mingw-w64 + GCC-4.7.2 from the MinGW-builds project: http://sourceforge.net/projects/mingwbuilds/

Romanesque

I don't know why the -Bstatic option doesn't seem to work, but you can probably get what you want by specifying the specific library file instead of letting ld search for it: https://mcmap.net/q/1018735/-how-to-force-ld-to-use-a-static-lib-instead-of-shared-lib – Horizontal

In my MinGW distribution the static archive is called libpthread.a (yes, the dynamic one is libwinpthread-1.dll too), therefore I'd rather use -lpthread. Probably the same is valid for yours. – Chauffer

Possible duplicate of how to do static linking of libwinpthread-1.dll in mingw? – Powerboat

Answer 1

Try this:

-static-libgcc -static-libstdc++ -Wl,-Bstatic -lstdc++ -lpthread -Wl,-Bdynamic

Notice the -lstdc++ before -lpthread. It worked for me.

Make sure to add this to the very end of your g++ command line.

Waltman

Why -lstdc++ before -lpthread when we already has -static-libstdc++?? – Spatz

@Spatz I don't know. It just works, and if I change the order it breaks. ;-) – Waltman

Works for me on MinGW 5.3 as well, statically adding the needed runtime libs to my own DLL. – Spence

Answer 2

Not ideal but if you do not mind plonking your runtime DLL's in the same directory as your executable, you can add something like this in your CMakeLists.txt file. This will copy the necessary DLL's from the MingW bin directory into the current build directory.

# ...
# change to name of your project
set(TARGET_NAME ${PROJECT_NAME})
# change to path to your minw bin directory
set(MINGW_BIN_PATH "C:\\Program Files\ \(x86\)\\mingw-w64\\i686-4.9.2-posix-dwarf-rt_v3-rev1\\mingw32\\bin")

set(LIBGCC_DLL "${MINGW_BIN_PATH}\\libgcc_s_dw2-1.dll")
add_custom_command(TARGET ${TARGET_NAME} PRE_BUILD
                   COMMAND ${CMAKE_COMMAND} -E copy
                   ${LIBGCC_DLL} $<TARGET_FILE_DIR:${TARGET_NAME}>)
set(LIBSTDCPP_DLL "${MINGW_BIN_PATH}\\libstdc++-6.dll")
add_custom_command(TARGET ${TARGET_NAME} PRE_BUILD
                   COMMAND ${CMAKE_COMMAND} -E copy
                   ${LIBSTDCPP_DLL} $<TARGET_FILE_DIR:${TARGET_NAME}>)
 set(LIBWINPTHREAD_DLL "${MINGW_BIN_PATH}\\libwinpthread-1.dll")
 add_custom_command(TARGET ${TARGET_NAME} PRE_BUILD
                    COMMAND ${CMAKE_COMMAND} -E copy
                    ${LIBWINPTHREAD_DLL} $<TARGET_FILE_DIR:${TARGET_NAME}>)

Unchaste

Answer 3

You are not doing anything incorrect, Mingw-Builds works that way you.

I recently stumbled on this, but for another reason:

Mingw-Builds automatically links executables to GCC dynamic libraries (libwinpthread-1.dll, libstdc++-6.dll, libgcc_s_dw2-1.dll) to save executable size (problem: when you release executables you have to remember to add missing dlls too along with your binary because there's no guarantee users have those DLL on their systems)

In my case the problem was that I had multiple GCC pakcages on the same system and hence I not added them to PATH to avoid name clashes.

The fun part is that CMAKE before configuring your project generates a C-SourceFile that is compiled and used to get informations about your compiler, since DLLs were not in PATH, that small executable generated by CMake was crashing because of missing DLLs and that stopped the whole build process.

The solution to fix that is adding the compiler path to PATH TEMPORARILY (or better run CMake in another environment).

Adding DLLs manually to the Cmake temp directory doesn't work because Cmake cleanup that directory at each configuration..

If you use mingwbuilds you have to link to pthreadBLAH.dll no workaround

Panicle