pthread_mutex_lock многократно определяется при использовании CMake 3.15, g ++ 8.2.0, MinGW, Windows 10 - PullRequest
Новая
       38

pthread_mutex_lock многократно определяется при использовании CMake 3.15, g ++ 8.2.0, MinGW, Windows 10

2 голосов
/ 21 сентября 2019

У меня проблемы с привязкой объектного файла к общей библиотеке для создания исполняемого файла в Windows.Компилятор жалуется на то, что pthread_mutex_lock и pthread_mutex_unlock определяются несколько раз.

Библиотека, на которую я ссылаюсь, - это библиотека, которую я создал.Должен сказать, что у меня проблемы только при попытке скомпилировать исполняемый файл в режиме DEBUG, когда библиотека также скомпилирована в режиме DEBUG.Нет проблем, когда оба компилируются в режиме RELEASE.Кроме того, он прекрасно работает в Ubuntu.

Makefile, который я использую для компиляции библиотеки, автоматически генерируется CMake, который был вызван командой 

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

Команда компиляции длякаждый файл библиотеки (в режиме DEBUG) имеет вид: 

/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

, где PATH - это путь к компилируемому файлу FILE.В конце концов библиотека скомпилирована в общий объект с помощью 

/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

Теперь ничего из вышеперечисленного не дает сбоя.Тем не менее, это не удается, когда я пытаюсь сделать исполняемый файл, связанный с библиотекой.На этот раз команда компиляции, выданная Makefile (сгенерированная с помощью CMake аналогично предыдущему), имеет вид 

/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

И выводимая ошибка: 

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

Я начинаю сужатьсяпроблема в том, неправильно ли связана библиотека или что -fopenmp появляется либо:

  • слишком много раз (при компиляции .cpp и .dll)
  • в неправильном месте (кажется, я использовал для компиляции .cpp (или .c) файлов с -fopenmp сразу после g++, а затем я создал исполняемый файл с -fopenmp в конце (как будто я связался сбиблиотеки, например -lgmp).

, но я не могу сказать, что не так с компоновкой библиотеки, как это делается, и еще меньше, что не так с -fopenmp в качестве команд компиляциидля режима RELEASE есть те же -fopenmp флаги.

Любая помощь будет оценена.

Пожалуйста, исправьте меня в любой ошибке, которую я мог допустить при написании этого поста. Также, если мойПодозрение о том, что флаг -fopenmp неуместен или выСлишком много раз неправильно, пожалуйста, скажите мне.Я также буду очень рад предоставить дополнительную информацию, если она понадобится.

Спасибо всем.

...