Используя библиотеку, написанную на C ++ из чистого проекта C на Linux? - PullRequest
Новая
       12

Используя библиотеку, написанную на C ++ из чистого проекта C на Linux?

5 голосов
/ 30 сентября 2011

Нашел это утверждение на PSE : (цитируя Боб )

Один из моих любимых приемов в Windows и Mac OS не работаетLinux.Этот трюк состоит в том, чтобы написать DLL / dylib с использованием внутренних компонентов C ++, экспортировать C API, а затем иметь возможность вызывать его из программ на C.Общие объекты Linux (локальный эквивалент DLL) не могут сделать это так просто, потому что стандартная библиотека C ++ не находится в пути поиска по умолчанию.Если вы не делаете кучу странных вещей с вашей C-программой, она потерпит неудачу, как только она динамически загрузит ваш .so во время выполнения: ваш .so попытается динамически загрузить стандартную библиотеку .so, он не найдетэто, и тогда ваша программа завершит работу.

Я считаю, что это немного странно.Насколько это точно, учитывая возможные различия между основными дистрибутивами Linux и Linux для настольных компьютеров?

Это просто из любопытства, так как в настоящее время я занимаюсь только Windows (C ++).

Что касается Windows, мне пришлось немного поискать, и я поставлю ее здесь для справки: исполняемый файл C ++ обычно ссылается на MSVCR * .DLL длябиблиотека C std и MSVCP * .DLL для материала STL, который находится в этой DLL.Оба они либо находятся в каталоге system32, либо, для проявленного материала, они будут находиться в подкаталоге кэша Windows SideBySide ( папка winsxs ).

1 Ответ

4 голосов
/ 30 сентября 2011

Я делаю эту вещь все время, и она отлично работает. Я почти уверен, что у этого парня была совершенно не связанная проблема, и он обвинил в этом пути поиска в библиотеке.

Я никогда не видел ни одного дистрибутива Linux, где libstdc++.so не находится на пути /usr/lib[64]/.

Что также заставляет меня задуматься о том, как программы C ++ обычно работают для этого парня, поскольку, насколько мне известно, путь поиска файлов .so не зависит от языка.

Может, он всегда использует специальную версию и компилирует все свои программы с опциями компоновщика -rpath? Но даже тогда простое добавление этой опции к его программам на Си тоже сработало бы.

произойдет сбой, как только он динамически загрузит ваш .so во время выполнения: ваш .so будет пытаться динамически загрузить стандартную библиотеку .so, она не будет найдите его, и ваша программа завершит работу.

Это заставляет меня задуматься, относится ли он исключительно к использованию dlopen() самостоятельно .so. Но и тогда он работает просто отлично, если только вы не связали .so с вашим libstdc++.so (что тогда было бы вашей собственной ошибкой; это было бы той же проблемой, если бы вы зависели от любой другой библиотеки, независимо от того, на каком языке это было написано в).

...