Непонимание относительно g ++, динамического и статического связывания на Linux против Windows

Question

Я немного смущен тем, что я узнал сегодня. Я надеюсь, что кто-нибудь может мне помочь.

Я понимаю концепцию динамического и статического связывания, но проблема заключается в следующем. В Windows или, по крайней мере, в парадигме Windows вы можете иметь .lib (который похож на .a) и .dll (который похож на .so, за исключением ... другого), и вы должны статически связываться в .lib, который содержит код, который вызывает функции из библиотеки DLL во время выполнения. Это правильно? Другими словами, gcc или g ++ должны иметь файлы .lib, доступные во время компиляции / компоновки, и иметь возможность находить файлы .dll во время выполнения. Пожалуйста, исправьте все неправильные предположения здесь.

Однако я делю несколько своих исходных файлов в своем небольшом приложении, потому что хочу сделать их библиотекой. Когда я запускаю g ++ на моих объектных файлах с опцией -shared, это в основном создает общую библиотеку (.so)? Вот где возникает путаница. Файл такой же , что требуется и во время соединения и во время выполнения? У меня проблемы с пониманием того, как мне это нужно в параметре -L / -l во время соединения, но ему все еще нужен файл во время выполнения. Это на самом деле норма? Dll принципиально отличается?

Наконец, последний вопрос. Возьмите библиотеку вроде boost на Windows. Я построил надстройку в соответствии с инструкциями. В конце каталог stage / lib содержит библиотеки в повторяющейся последовательности name.a, name.dll.a, name.dll. Какова цель этой схемы? Я знаю, что мне нужны dll-файлы во время выполнения, но когда я использую опцию -L / -l во время компоновки, какие файлы используются при THEN?

Извините, если это действительно рассеяно, но я надеюсь, что кто-то может помочь прояснить это. Большое спасибо!

Answer 1

В Windows, или, по крайней мере, в Windows существует парадигма. Вы можете иметь .lib (который похож на .a) и .dll (который похож на .so, кроме ... другого), и вы должны статическиссылка в .lib, которая содержит код, который вызывает функции из библиотеки DLL во время выполнения.Это правильно?

Да и нет.Это один из способов работы DLL в Windows, но это не единственный способ.

Вы можете загрузить DLL вручную, используя вызовы Win32 API.Но если вы это сделаете, вы должны вручную получить указатели на функции для доступа к DLL.Цель библиотеки импорта (той статической библиотеки, о которой вы говорите) состоит в том, чтобы сделать это автоматически.

Приятно делать это вручную, потому что вы можете выбирать, какие библиотеки DLL вам нужны.Вот как некоторые приложения предоставляют поддержку плагинов.Пользователи пишут DLL, которая экспортирует четко определенный набор функций API.Ваша программа загружает их из каталога, и они связывают указатели функций для каждой библиотеки DLL в свой собственный объект, который представляет интерфейс для этого плагина.

GCC работает так же, в Windows ,Сборка DLL производит DLL и библиотеку импорта.Это файл ".a" вместо ".lib" из-за компилятора, но он все равно делает то же самое.

В Linux файлы .so представляют собой комбинацию .dll и библиотеки импорта.Таким образом, вы ссылаетесь на .so при компиляции рассматриваемой программы, и она выполняет ту же работу, что и ссылка на библиотеку импорта.

Answer 2

Это всего лишь два способа предоставления информации во время компиляции об общей библиотеке. Может быть, сравнение объясняет это лучше?

В Windows это: «Вы будете использовать общую библиотеку (.dll), а здесь (.a или .dll.a) - руководство по ее использованию».

В Linux это: «Вы будете использовать общую библиотеку (.so), поэтому посмотрите на нее заранее (.so), чтобы вы знали, как ее использовать».