[MSYS2][Windows 7][порт общей библиотеки из Linux] Есть ли эквивалент ldconfig в MSYS2?

В образовательных целях я использую личную библиотеку под названием uepwide. Он содержит множество функций для использования консольной (терминальной) среды в Linux. Поскольку я использую то, что, как ожидается, будет переносимым, называемым функциями POSIX и UTF8 GNU (связанными с wchar.h), я попытался перенести его в среду Windows через среду MSYS2 (Cygwin не работает).

Я использую make-файл из Linux и пробовал другую версию для Windows... так как уже 19 лет я не прикасаюсь к среде Windows для целей программирования, я забыл все, что касается dll, которые работают в Windows. Я просто надеюсь, что нет необходимости включать такие вещи, как __declspec(dllimport) и т.д... в каждый тестовый исходный код, используемый в Linux, чтобы проверить, все ли в порядке с общей библиотекой, превращенной в dll.

Вот makefile (часть Windows), который я использовал:

dllwin:     uep_wide.c uep_wide.h setElementEx.c getElementEx.c
        @echo "Librairie partagée compilée..."
        @echo "...installation au niveau du système d'exploitation !!"
        gcc -c -fPIC -O3 uep_wide.c -o libuepwide.o
        @echo "...compilation des add-ons..."
        gcc -c -fPIC -O3 setElementEx.c -o setElementEx.o
        gcc -c -fPIC -O3 getElementEx.c -o getElementEx.o
        gcc -c -fPIC -O3 getPIDByName.c -o getPIDByName.o
        @echo "...compilation de la librairie..."
        gcc -shared -Wall libuepwide.o setElementEx.o getElementEx.o getPIDByName.o -lpthread -lm -o uepwide.dll 
        @cp uepwide.dll /usr/lib
        @echo "TERMINE"

Поскольку в MSYS2 нет папки lib64 (почему?), то я поместил ее в /usr/lib. Когда я компилирую свой тестовый код, пытаясь использовать эту dll...

CFLAGS=`pkg-config uepwide linkedlist --cflags`
LDFLAGS=`pkg-config uepwide linkedlist --libs`

test1: test1.c
test2: test2.c
test3: test3.c
test4: test4.c
...

Я получил эту ошибку от компоновщика...

cc `pkg-config uepwide --cflags`  `pkg-config uepwide --libs`  test1.c   -o test1
/usr/lib/gcc/x86_64-pc-msys/10.2.0/../../../../x86_64-pc-msys/bin/ld: cannot find -luepwide
collect2: error: ld returned 1 exit status
make: *** [<builtin>: test1] Error 1

Это показывает, что pkg-config работает, но uepwide неизвестен MSYS2/Windows, потому что эта dll не была зарегистрирована, как это делает ldconfig в Linux.

Как зарегистрировать эту dll?

[EDIT 1] Это файл uepwide.pc:

libdir=/usr/lib
includedir=/librairies/uep_wide
Libs: -L${libdir} -luepwide -lpthread -lm
Cflags: -I${includedir}

[РЕДАКТИРОВАТЬ 2] Поскольку MSYS2 кажется средой "три в одном" (см. комментарии), я просмотрел структуру папок и увидел, что существует шесть мест, где локализован pkgconfig...

  • c:\msys64\usr\lib
  • c:\msys64\usr\share
  • c:\msys64\mingw32\lib
  • c:\msys64\mingw32\общий доступ
  • c:\msys64\mingw64\lib
  • c:\msys64\mingw64\общий доступ

Те, которые относятся к выбранной среде MSYS2 MSYS, выделены курсивом и полужирным шрифтом. Поэтому я поместил dll в /usr/lib, так как *c:\msys64* chrooted.

[EDIT 3] Поскольку я не хочу ничего менять в исходном коде для каждого тестового приложения, я буду следовать подсказке, указывающей, что в Windows - я забыл - dll сначала ищутся в папке, а затем в PATH. Так как я не хочу менять #include ‹uep_wide.h› на #include uep_wide.h (именно поэтому я использую pkg-config), я проверю правильность PATH.

[EDIT 4] Очень занят, извините за опоздание... Он работает с использованием dll в /usr/bin вместо /usr/lib. С другой стороны, у Windows, похоже, есть проблемы с повторением символов utf8. Нужно отладить, что не так.


person Hurukan Imperial Stepper    schedule 22.03.2021    source источник
comment
Я поместил dll в /usr/lib dll принадлежат bin, а не lib. На MinGW, по крайней мере до определенной версии, нельзя было напрямую ссылаться на dll. Вместо этого запись -lfoo, среди прочего, пытается связать заглушку libfoo.dll.a, которая затем загружает dll во время выполнения. Я бы не стал полагаться на прямое связывание с dll и вместо этого использовал этот метод. (Таким образом, только libuepwide.dll.a должен быть в пути поиска компоновщика (во время компиляции), а не в dll.   -  person HolyBlackCat    schedule 24.03.2021
comment
не хочу менять #include ‹uep_wide.h› на #include uep_wide.h... Я проверю правильность PATH Мой комментарий по поводу PATH относится только к среде выполнения поиск dll. Поиск во время компиляции, выполняемый компоновщиком (и поиск по заголовку), не должен быть затронут. Вы должны хранить только каталог bin в PATH, а не lib или include.   -  person HolyBlackCat    schedule 24.03.2021


Ответы (1)


Вы эффективно используете Cygwin прямо сейчас.

MSYS2 имеет три режима. Текущий режим отображается пурпурным текстом в терминале: MSYS, MINGW32 или MINGW64. Режимы отличаются переменными среды, в первую очередь PATH.

Режимы имеют три соответствующих набора пакетов, включая компиляторы и библиотеки. Имена пакетов начинаются с префиксов, указывающих на их режимы.

  • Пакеты MINGW32 имеют префикс mingw-w64-i686-. Они используются для компиляции для 32-битной Windows.
  • Пакеты MINGW64 имеют префикс mingw-w64-x86_64-. Они используются для компиляции для 64-битных окон.
  • Пакеты MSYS не имеют префикса, они используются для компиляции того, что по сути является собственной вилкой Cygwin для MSYS2.

Все бинарники в каждой группе пакетов собираются соответствующими компиляторами.

Вы почти никогда не захотите использовать режим MSYS. (Если вам нужен Cygwin, вы можете использовать сам Cygwin).

Может быть, вы можете заставить его работать в режиме MSYS, но я предлагаю переключиться на MINGW64. Включите его, запустив оболочку с помощью mingw64.exe.

Если вы используете MINGW64, вы должны предпочесть пакеты с префиксом mingw-w64-x86_64- пакетам без префикса: вы используете пакеты с префиксом для всех компиляторов и библиотек, а пакеты без префикса только для утилит, которые не имеют ничего общего со сборкой, таких как bash, make, grep - которые не имеют префиксных альтернатив (ну, у Make есть, но это ерунда).

Файлы, относящиеся к MINGW32 и MINGW64, находятся в /mingw32 и /mingw64. Файлы, относящиеся к MSYS, находятся в /.

Поэтому вам нужно использовать /mingw64/lib вместо /usr/lib.

person HolyBlackCat    schedule 22.03.2021
comment
Спасибо. При компиляции с помощью MINGW64 файл termios.h не найден. Единственная среда, которая позволила мне скомпилировать мою библиотеку, — это MSYS. - person Hurukan Imperial Stepper; 23.03.2021
comment
hurukan@VirtualWin7 MINGW64 /usr/include # ls -lah termios.h -rw-r--r-- 1 hurukan None 92 Mar 17 09:17 termios.h вот что я нашел. - person Hurukan Imperial Stepper; 23.03.2021
comment
uep_wide.c:24:10: fatal error: termios.h: No such file or directory 24 | #include <termios.h> | ^~~~~~~~~~~ compilation terminated. make: *** [makefile:29: dllwin] Error 1 вот что у меня есть... - person Hurukan Imperial Stepper; 23.03.2021
comment
под MSYS компилируется без ошибок. - person Hurukan Imperial Stepper; 23.03.2021
comment
... но я не могу ни с чем связать dll... эквивалент ldconfig отсутствует... - person Hurukan Imperial Stepper; 23.03.2021
comment
@HurukanImperialStepper В Windows путь поиска DLL во время выполнения всегда является каталогом .exe, затем некоторыми системными каталогами, затем PATH. Но компоновщик (во время сборки) может не искать их, он ищет каталоги, которые вы ему указываете с помощью -L…. Предлагаю установить какую-нибудь случайную библиотеку из менеджера пакетов, и посмотреть какие файлы куда помещаются, и что в .pc файле. - person HolyBlackCat; 23.03.2021