#c #c #windows #linux #shared-libraries
#c #c #Windows #linux #разделяемые библиотеки
Вопрос:
Нашел это утверждение в PSE: (цитирую Боба)
Один из моих любимых приемов в Windows и Mac OS не работает в Linux. Этот трюк заключается в том, чтобы написать DLL / dylib, используя внутренние компоненты C , экспортировать C API, а затем иметь возможность вызывать его из программ на C. Общие объекты Linux (локальный эквивалент DLL) не могут сделать это легко, потому что стандартная библиотека C .so не находится в пути поиска по умолчанию. Если вы не сделаете кучу странных вещей в своей программе на C, она завершится с ошибкой, как только она динамически загрузит вашу .so во время выполнения: your .so попытается динамически загрузить стандартную библиотеку . таким образом, он ее не найдет, и тогда ваша программа завершится.
Я нахожу это немного странным. Насколько это точно, учитывая возможные различия между основными настольными / серверными дистрибутивами Linux?
Это чисто из любопытства, поскольку на данный момент я программирую только на Windows (C ).
Что касается Windows, мне пришлось немного поискать, и я приведу его здесь для справки: исполняемый файл C обычно ссылается на MSVCR * .DLL для библиотеки C std и MSVCP * .DLL для содержимого STL, которое находится в этой DLL. Оба они либо находятся в каталоге system32, либо, для проявленного материала, они будут находиться в подкаталоге Windows SideBySide cache (папка winsxs).
Комментарии:
1.
I find that a bit odd. Is this accurate?да, это странно. Нет, это не точно. Кроме того, не существует такого понятия, как «linux» (дистрибутивы отличаются)2. Обратите внимание, что (из памяти:) Среда выполнения VS2008 MSVC должна загружаться с помощью манифеста (иначе ваша программа будет жаловаться во время загрузки)
3. @sehe — Кажется странным, что основные дистрибутивы значительно отличаются.
4. Я не говорю, что существует дистрибутив, в котором нет битов libstdc в пути поиска; Я говорю, что нечетное утверждение может быть верным для какого-то иностранного дистрибутива Linux (встроенный Linux для чипсетов Epson, используемых в холодильниках?)
5. Я делаю это все время, и это работает нормально. Я почти уверен, что у этого парня была совершенно не связанная с этим проблема, и он обвинил в этом пути поиска в библиотеке. Я никогда не видел ни одного linux, где libstdc отсутствует в /usr/lib[64]/ path
Ответ №1:
Я делаю это все время, и это работает нормально. Я почти уверен, что у этого парня была совершенно не связанная с этим проблема, и он обвинил в этом пути поиска в библиотеке.
Я никогда не видел ни одного дистрибутива Linux, в котором libstdc .so нет /usr/lib[64]/ пути.
Что также заставляет меня задуматься, как программы на C обычно работают для этого парня, поскольку, насколько мне известно, путь поиска .so файлов не зависит от языка.
Может быть, он всегда использует специальную версию и компилирует все свои программы с -rpath параметрами компоновщика? Но даже тогда простое добавление этой опции в его программы на C тоже сработало бы.
он завершится неудачей, как только динамически загрузит ваш .so во время выполнения: your .so попытается динамически загрузить стандартную библиотеку . таким образом, он ее не найдет, и тогда ваша программа завершит работу.
Это заставляет меня задуматься, относится ли он исключительно к использованию dlopen() самостоятельно .so . Но и тогда она работает просто отлично, если только вы не связали .so ее со своей libstdc .so (что было бы вашей собственной ошибкой; это была бы та же проблема, если бы вы зависели от любой другой библиотеки, независимо от того, на каком языке она была написана).