Мысль #2
Динамическая линковка и как прийти к подобию совершенства в архитектуре
Как известно, после получения объектного кода наступает этап линковки и тут у нас два возможных сценария: линковаться статически или динамически. И оба метода вполне актуальны и имеют свои кейсы, вопрос только в рациональности использования. Небольшой экскурс до "начала времени" Unix: изначально в system lll использовалась статическая линковка в формат а.out, который в душе не чаял, что такое эти ваши динамические библиотеки, от чего, да и не только, у разработчиков весьма подгорало, и сели они и айда думать, как же решить эту беду и придумали они как один из вариантов формат исполняемых файлов ELF, исполняемый линкуемый файл, привычный, но не единственный, в разновидностях *NIX'ов, позволявший подгружать символы вне сегментов загруженного в память бинарника, а уже посредством другой статической сущности передавать управление или принимать данные из других таких же объектов, что с одной стороны, позволяет не загружать повторно уже имеющиеся функции в память, а делить их между приложениями, от чего их так же называют shared object'ами в заморской литературе, но с другой, усложнило загрузку самих программ и вероятность ошибок при их обработке, в лице отсутствия нужных точек входа/символов, что есть синонимы, DLL hell, когда каждое приложение тащит одну и ту же библиотеку много раз и они плодятся как кролики по всей системе, ошибок сегментирования, так как что-то вне бинарника могло измениться и так далее. Есть системы где статических бинарников по сути нет и они не разрешены в документации, в таких системах все приложения являются по сути своей библиотеками или же обьектами, способными быть загруженными другими объектами, в частности к таким относятся Mac OS X и Haiku, где из статических объектов существуют только непосредственно сущности, связанные с разбором динамических объектов, dyld и runtime-loader соответственно. И динамическая линковка так же дала возможность более гибко работать с софтом, ибо теперь у вас нет необходимости держать строго одну версию ПО, поскольку если совместимость по символам есть, вы без проблем можете обновиться и для программ это будет максимально незаметно в большинстве случаев. А теперь, главный вопрос всея опеннета, вечный, как мем про патченные кеды в FreeBSD: зачем? Динамическая линковка хороша если ваша программа часто обновляется, в ней нет специфичных функций из сторонних библиотек или выкинутого из их новых версий функционала. Но это вам может и помешать, к примеру, когда у вас есть конкретные требования к версиям библиотек или функциям, и они не приняты в апстриме, или же ваша программа с закрытыми исходниками(упаси Линус вас такое делать), то вам прямая дорога включать такие библиотеки статически в ваше приложение.
Так что, анализируйте, делайте выводы, линкуйте с умом и будет вам Nirvana
А на этом у меня всё, до следующей дельной мысли!??
(Пы.$ы.:правки и замечания приветствуются)
Динамическая линковка и как прийти к подобию совершенства в архитектуре
Как известно, после получения объектного кода наступает этап линковки и тут у нас два возможных сценария: линковаться статически или динамически. И оба метода вполне актуальны и имеют свои кейсы, вопрос только в рациональности использования. Небольшой экскурс до "начала времени" Unix: изначально в system lll использовалась статическая линковка в формат а.out, который в душе не чаял, что такое эти ваши динамические библиотеки, от чего, да и не только, у разработчиков весьма подгорало, и сели они и айда думать, как же решить эту беду и придумали они как один из вариантов формат исполняемых файлов ELF, исполняемый линкуемый файл, привычный, но не единственный, в разновидностях *NIX'ов, позволявший подгружать символы вне сегментов загруженного в память бинарника, а уже посредством другой статической сущности передавать управление или принимать данные из других таких же объектов, что с одной стороны, позволяет не загружать повторно уже имеющиеся функции в память, а делить их между приложениями, от чего их так же называют shared object'ами в заморской литературе, но с другой, усложнило загрузку самих программ и вероятность ошибок при их обработке, в лице отсутствия нужных точек входа/символов, что есть синонимы, DLL hell, когда каждое приложение тащит одну и ту же библиотеку много раз и они плодятся как кролики по всей системе, ошибок сегментирования, так как что-то вне бинарника могло измениться и так далее. Есть системы где статических бинарников по сути нет и они не разрешены в документации, в таких системах все приложения являются по сути своей библиотеками или же обьектами, способными быть загруженными другими объектами, в частности к таким относятся Mac OS X и Haiku, где из статических объектов существуют только непосредственно сущности, связанные с разбором динамических объектов, dyld и runtime-loader соответственно. И динамическая линковка так же дала возможность более гибко работать с софтом, ибо теперь у вас нет необходимости держать строго одну версию ПО, поскольку если совместимость по символам есть, вы без проблем можете обновиться и для программ это будет максимально незаметно в большинстве случаев. А теперь, главный вопрос всея опеннета, вечный, как мем про патченные кеды в FreeBSD: зачем? Динамическая линковка хороша если ваша программа часто обновляется, в ней нет специфичных функций из сторонних библиотек или выкинутого из их новых версий функционала. Но это вам может и помешать, к примеру, когда у вас есть конкретные требования к версиям библиотек или функциям, и они не приняты в апстриме, или же ваша программа с закрытыми исходниками(упаси Линус вас такое делать), то вам прямая дорога включать такие библиотеки статически в ваше приложение.
Так что, анализируйте, делайте выводы, линкуйте с умом и будет вам Nirvana
А на этом у меня всё, до следующей дельной мысли!??
(Пы.$ы.:правки и замечания приветствуются)
