samedi 21 septembre 2019

CMake 3.15, g++ 8.2.0, MinGW, Windows 10, and pthread_mutex_lock

I'm having some troubles in linking an object file against a shared library to create an executable file on Windows. The compiler complains about pthread_mutex_lock and pthread_mutex_unlock being defined multiple times.

The library I'm linking against is a library that I've made. I must say that I'm only having troubles when I'm trying to compile the executable in DEBUG mode when the library is also compiled in DEBUG mode. There is no problem when both are compiled in RELEASE mode. Also, it works fine in Ubuntu.

The Makefile I'm using to compile the library is generated automatically by CMake, which has been invoked with the command

cmake -G "MSYS Makefiles" -DCMAKE_C_COMPILER=gcc -DCMAKE_CXX_COMPILER=g++ -DCMAKE_INSTALL_PREFIX:PATH=C:/programming/c++ -DCMAKE_BUILD_TYPE=Debug ../lal

The compilation command for every file of the library (in DEBUG mode) is of the form:

/C/programming/MinGW/bin/g++.exe  -Dlal_EXPORTS @CMakeFiles/lal.dir/includes_CXX.rsp -fopenmp -g -DDEBUG -D_GLIBCXX_DEBUG   -Wrestrict -std=gnu++11 -o CMakeFiles/lal.dir/properties/FILE.obj -c PATH/FILE

where PATH is the path to the file FILE that is being compiled. The library is finally compiled into a shared object with

/C/programming/cmake-3.15.0/bin/cmake.exe -E remove -f CMakeFiles/lal.dir/objects.a
/C/programming/MinGW/bin/ar.exe cr CMakeFiles/lal.dir/objects.a @CMakeFiles/lal.dir/objects1.rsp
/C/programming/MinGW/bin/g++.exe   -fopenmp -g -DDEBUG -D_GLIBCXX_DEBUG  -shared -o liblal.dll -Wl,--out-implib,liblal.dll.a -Wl,--major-image-version,2019,--minor-image-version,7 -Wl,--whole-archive CMakeFiles/lal.dir/objects.a -Wl,--no-whole-archive @CMakeFiles/lal.dir/linklibs.rsp

Now, nothing of the above fails. However, it does fail when I try to make an executable file linked against the library. This time, the compilation command issued by the Makefile (generated using CMake similarly as before) is

/C/programming/cmake-3.15.0/bin/cmake.exe -E remove -f CMakeFiles/all_free_lab_trees.dir/objects.a
/C/programming/MinGW/bin/ar.exe cr CMakeFiles/all_free_lab_trees.dir/objects.a @CMakeFiles/all_free_lab_trees.dir/objects1.rsp
/C/programming/MinGW/bin/g++.exe  -fopenmp -g -DDEBUG -D_GLIBCXX_DEBUG   -Wl,--whole-archive CMakeFiles/all_free_lab_trees.dir/objects.a -Wl,--no-whole-archive  -o all_free_lab_trees.exe -Wl,--out-implib,liball_free_lab_trees.dll.a -Wl,--major-image-version,0,--minor-image-version,0 @CMakeFiles/all_free_lab_trees.dir/linklibs.rsp

And the error that it outputs is

c:/programming/mingw/bin/../lib/gcc/x86_64-w64-mingw32/8.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: c:/programming/mingw/bin/../lib/gcc/x86_64-w64-mingw32/8.2.0/../../../../x86_64-w64-mingw32/lib/../lib/libpthread.a(libwinpthread_la-mutex.o):mutex.c:(.text+0x70): multiple definition of `pthread_mutex_lock'; C:/programming/c++/lib/../lib/liblal.dll.a(d003219.o):(.text+0x0): first defined here
c:/programming/mingw/bin/../lib/gcc/x86_64-w64-mingw32/8.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: c:/programming/mingw/bin/../lib/gcc/x86_64-w64-mingw32/8.2.0/../../../../x86_64-w64-mingw32/lib/../lib/libpthread.a(libwinpthread_la-mutex.o):mutex.c:(.text+0x320): multiple definition of `pthread_mutex_unlock'; C:/programming/c++/lib/../lib/liblal.dll.a(d003222.o):(.text+0x0): first defined here

I'm starting to narrowing the problem to whether the linkage of the library is wrong or that -fopenmp appears either:

  • too many times (when compiling the .cpp and the .dll)
  • in the wrong place (I think I used to compile .cpp (or .c) files with -fopenmp right after g++ and then I created the executable file with -fopenmp at the end (as if I linked against a library, like -lgmp).

but I can't tell what is wrong with linking the library the way it's done, and even less what is wrong with -fopenmp as the compilation commands for RELEASE mode have the same -fopenmp flags.

Any help will be appreciated.

Please, correct me in any mistake that I could have made when writing this post. Also, if my suspicion about the flag ``-fopenmp``` being misplaced or used too many times is wrong, please tell me. I will also be very happy to provide more information in case it is needed.

Thank you all.

Aucun commentaire:

Enregistrer un commentaire