dyld: сбой привязки ленивого символа при попытке статической ссылки на dylib в swift

Я создал файл dylib, используя fpcupdeluxe в freepascal, только с одной функцией cdecl _test, доступной как для 1) MacOS, так и 2) Debian (кросс-скомпилирован в x86_64 darwin)

Я пробовал вызвать dylib, используя 1) dlopen 2) мостовой заголовок 3) Framework

Dylib, скомпилированный на MacOS, работал со всеми тремя методами. Однако, когда я заменил этот dylib на тот, который я скомпилировал на debian, похоже, работает только dlopen, другие 2 метода, использующие заголовок моста и фреймворк, дали мне эту ошибку: dyld: lazy symbol binding failed: Symbol not found: _test

Я сделал nm -gU на обоих dylib, и только относительный виртуальный адрес функции _test отличается, что я могу сделать, чтобы исследовать причину этого и решить ее?

otool -L для

Нерабочий

XXXXX.dylib: /home/wire/fpcupdeluxe/projects/XXXXX.dylib (версия совместимости 0.0.0, текущая версия 0.0.0) /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit (версия совместимости 45.0.0). 0, текущая версия 1404.0.0) /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation (версия совместимости 300.0.0, текущая версия 1252.0.0) /System/Library/Frameworks/CoreFoundation.framework/Versions/ A / CoreFoundation (версия совместимости 150.0.0, текущая версия 1253.0.0) /usr/lib/libSystem.B.dylib (версия совместимости 1.0.0, текущая версия 1225.1.1)

Работающий

/Users/wire/XXXXX.dylib: /Users/wire/XXXXX.dylib (версия совместимости 0.0.0, текущая версия 0.0.0) /usr/lib/libSystem.B.dylib (версия совместимости 1.0.0, текущая версия 1281.100 .1)

Где XXXXX - это имя моей библиотеки, я также заметил, что путь для рабочей и нерабочей библиотеки отличается. В нерабочем случае мой dylib указывает на каталог на моей Linux-машине, который не должен присутствовать на Mac. Я также попытался выполнить кросс-компиляцию в Windows, и путь был в C: \, и ошибка была не найдена, мне нужно изменить этот путь? Я новичок в программировании MacOS


person user962460    schedule 08.04.2020    source источник
comment
Вы должны различать двоичные файлы dylib с помощью таких инструментов, как otool, jtool или, если вы предпочитаете инструменты пользовательского интерфейса, MachOExplorer или MachOTool для проверки и сравнения команд загрузки Mach-O.   -  person Kamil.S    schedule 08.04.2020
comment
Хороший. Я рекомендую удалить LC_LOAD_DYLIB для AppKit и Foundation из двоичного файла dylib, который создается цепочкой кросс-компилятора Debian. Вы можете добиться этого, используя метод, который я описал в своем ответе здесь stackoverflow.com/questions/60497896/ jtool2 доступен как в MacOS, так и в Linux. Поступая так, вы должны хотя бы узнать, виноваты ли эти дополнительные фреймворки или что-то еще.   -  person Kamil.S    schedule 08.04.2020
comment
Я удалил LC_LOAD_DYLIB в соответствии с сообщением, но когда я снова делаю otool -L, я получаю усеченный или искаженный объект (поле файла команды загрузки 2 плюс поле размера файла в LC_SEGMENT_64 выходит за пределы конца файла) ./jtool2 -L производит / usr /lib/libSystem.B.dylib (версия совместимости 1.0.0, текущая версия 1225.1.1), и мой xcode не может быть собран; (   -  person user962460    schedule 08.04.2020
comment
не могли бы вы включить все команды загрузки для обоих дилибов для сравнения? Чем больше информации вы предоставите, тем больше шансов, что кто-то сможет помочь.   -  person Kamil.S    schedule 08.04.2020
comment
Единственный LC_LOAD_DYLIB, который я исключил, был мой собственный dylib   -  person user962460    schedule 09.04.2020
comment
Я только что обновил свой ответ   -  person user962460    schedule 09.04.2020
comment
вам нужно использовать относительный путь, а не абсолютный путь   -  person Kamil.S    schedule 09.04.2020
comment
Как мне изменить его как в кросс-скомпилированном dylib, так и в настройках моего проекта?   -  person user962460    schedule 09.04.2020
comment
Спасибо, разберусь   -  person user962460    schedule 09.04.2020
comment
Хорошо, что выполнила свою работу, большое спасибо, жаль, что я не могу дать вам больше очков репутации :)   -  person user962460    schedule 10.04.2020
comment
пожалуйста, опубликуйте решение, которое решает вашу проблему, в качестве ответа для будущих читателей.   -  person Kamil.S    schedule 10.04.2020


Ответы (1)


Благодаря Kamil.S я нашел решение, в котором мне просто нужно было запустить install_name_tool -id @ rpath /, чтобы установить для него относительный путь, поскольку в отличие от Windows все пути к динамическим библиотекам хранятся в самой структуре mach-o

person user962460    schedule 12.04.2020
comment
Посмотрите copy_dylibs.py скрипт в этом репозитории git, который должен делать все install_name_tool махинации за вас. - person trojanfoe; 12.04.2020