Теоретически это возможно, но есть много причин не делать этого. На практике «динамическое связывание» на самом деле не является полной связью; независимый от позиции код используется для всех, кроме основной программы (и, возможно, для основной программы), в результате чего полный диапазон перемещений, который может потребоваться для полного (статического) компоновщика, не требуется. Вместо этого требуется лишь небольшое количество типов переселения, которые в основном сводятся к заполнению адресов функций и объектов, содержащихся в библиотеках в большой смежной таблице. Конечно, такие ссылки в объектах статической продолжительности хранения в сегменте .data
также должны быть заполнены, поэтому это немного больше работы, чем просто заполнение смежной таблицы, но ключевым моментом является то, что изменены только данные, а не код. ,
Если вы вообще начинаете изменять код, вы выбрасываете большинство преимуществ динамической компоновки: кодовые страницы не могут быть разделены между несколькими экземплярами приложения/библиотеки, и гораздо больше времени будет потрачено на дублирование при запуске (через ошибки страниц и семантику копирования на запись) отображаемые кодовые страницы. И это всего лишь минимальные затраты на исправление нескольких байтов здесь и там в коде.
Для фактического ввода кода из динамических библиотек то, что вам нужно было бы сделать, это полная оптимизация времени ссылки. Измерить, сколько времени потребуется LTO-link для большой программы, а затем спросить себя, будут ли пользователи приемлемыми, ожидая этого, каждый раз, когда они запускают программу. Ответ почти наверняка нет.
Если поставщик библиотеки предполагает, что небольшие функции являются встроенными, они могут предоставлять определения для таких функций в файле заголовка, который сопровождает библиотеку. – jxh
Обратите внимание, что метод @jxh, предложенный, должен использоваться только в том случае, если структуры данных, которые функционируют в библиотеке, являются частью общедоступного API. Если нет, эти встроенные функции будут включать в себя знания, не связанные с публичными API-интерфейсами библиотеки данных, в приложения, созданные против библиотеки, и если будущая версия библиотеки хочет внести какие-либо изменения в эти непубличные структуры, приложения сильно сломаются если используется с новой версией библиотеки. Это можно решить с помощью библиотечного управления версиями, но затем вы вынуждаете пользователей хранить старые версии библиотек ... –