LINUX.ORG.RU

Статическое и динамическое связывание

 


0

2

Приветствую,

Прошу пожалуйста сильно не пинать за вопрос.

Я наткнулся на такое вот описание: CEF

Введение Visual Studio поддерживает несколько библиотек времени выполнения. Различные библиотеки обозначаются такими флагами, как /MD, /MTи /LD. По умолчанию CEF использует /MTфлаг, который также используется в проекте Chromium. Однако для разных приложений иногда могут потребоваться разные библиотеки времени выполнения.

Подробности В настоящее время существует два способа связать CEF с вашим приложением.

Статическое связывание (без DLL CEF) Если вы хотите связать CEF со своим приложением статически, то все проекты Chromium и CEF должны использовать тот же флаг времени выполнения, что и ваше приложение. Если ваше приложение уже использует этот /MTфлаг, вы можете статически собрать CEF следующим образом:

Настройте среду, необходимую для сборки Chromium и CEF, как описано на странице проекта, и соберите ее. Свяжите свое приложение с результирующим файлом libcef_static.lib. Однако, если ваше приложение не использует этот /MTфлаг, вам не повезло. Важные части Chromium не будут компилироваться с другим флагом, кроме /MT.

Флаги майкрософтофского компилятора /MT и /MD - создают или статический CRT или динамически подгружаемым CRT во время выполнения приложения, я так понимаю аналог в Linux - это libc.so(MD) и libc.a(MT).

А вопрос такой: Я что то не понимаю: тут написано, что если вы хотите связать CEF с вашим приложением статически, то ваше приложение должно использовать тот же флаг, что и CEF(/MT).

Не подменяются ли тут понятия - статического связывания библиотеки времени выполнения Си и статического связывания самого проекта с другим проектом ?

Они, похоже, просто говорят, что и CEF и приложение должно использовать стандартную библиотеку одинаковым образом. Т.е. не должно быть так, что CEF использует её динамически, а приложение статически, или наоборот.

В линуксе glibc вроде и не может быть полностью статической и по умолчанию всё линкуется динамически, так что не должно быть нужды об этом беспокоиться.

xaizek ★★★★★
()
Ответ на: комментарий от xaizek

В линуксе glibc вроде и не может быть полностью статической и по умолчанию всё линкуется динамически, так что не должно быть нужды об этом беспокоиться.

Только если это не musl (например alpine)

anonymous
()
Ответ на: комментарий от anonymous

Только если это не musl (например alpine)

Так я и написал glibc, а не libc.

xaizek ★★★★★
()

Не подменяются ли тут понятия

Как выше уже сказали - нет.

если вы хотите связать CEF с вашим приложением статически, то ваше приложение должно использовать тот же флаг, что и CEF(/MT).

Да, кстати, недавно комментировал по этой теме: Новый формат изображений быстрее PNG в десятки раз (комментарий).

gag ★★★★★
()

например у меня было что FILE* открытое статической rtl крашило программу при попытке передать его в stdio функцию из динамического msvcrt.dll то ли наоборот

anonymous
()
Ответ на: комментарий от xaizek

Они, похоже, просто говорят, что и CEF и приложение должно использовать стандартную библиотеку одинаковым образом.

Не знаю откуда ТС это принес, но в таком использовании libc нет нужды - все объекты CEF аллоцируются и деаллоцируются в libcef.

Касательно официальной доки на английском, то там говорится про библиотеку, libcef_wrapper, которая статически линкуется к приложению, но имеет динамическую линковку к libcef.

SR_team ★★★★★
()
Ответ на: комментарий от xaizek

В линуксе glibc вроде и не может быть полностью статической

если точнее то часть её функций не может, а если их не использовать то можно

но тут речь не про это, компиляция с ключом -static следует считать статической

anonymous
()
Ответ на: комментарий от anonymous

например у меня было что FILE* открытое статической rtl крашило программу при попытке передать его в stdio функцию из динамического msvcrt.dll то ли наоборот

Тоже помню подобное. Лет 20+ назад, когда ещё писал на плюсах под венду. =)

dimgel ★★★★★
()
Ответ на: комментарий от dimgel

Под онтопик будет тоже самое, если вся прога слинкованна статически, а потом ты вдруг берёшь какую-то системную либу, даже с тем же ABI, но с динамически прилинкованным рантаймом(пусть даже и той же версии, а если другой то это вообще «удачной отладки»). Но собрать под онтопик что-то настолько статическое - это «непринято» что-ли, хотя можно. А под винду - это очень распространённая практика.

faq2
()
Ответ на: комментарий от faq2

Под онтопик будет тоже самое

Логично. Получается, что заюзано два экземпляра системной либы (один статически прилинкован, другой динамически), управляющие двумя разными memory pools. Остаётся дождаться, когда код (допустим приложения), прилинкованный к одному экземпляру, попытается высвободить память, выделенную кодом (допустим либы), прилинкованным к другому экземпляру, – и превед. Да и прочие всякие глобальные переменные (типа errno) у них будут задвоены.

dimgel ★★★★★
()
Последнее исправление: dimgel (всего исправлений: 1)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.