LINUX.ORG.RU

Линковка со статическими и динамическими библиотеками


0

0

Доброго времени суток! Периодически приходится собирать библиотеки из исходного кода, обратил внимание на то, что размеры файлов полученные с помощью dpkg-buildpackage (система Debian sid amd64) и, например, configure + make различаются в разы.

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

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

разница в том, что система сборки пакета может использовать ключи --with-чтото --without-чтото --disable-чтото

а также ключики компоновщика --as-needed

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

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

а еще хорошо бы знать то, что если вы все равно будете делать strip
то можно задавать умолчания для флагов перед сборкой

export CFLAGS="-O2 -g0"
export CXXFLAGS="-O2 -g0"

если не заданы, то используется -O2 -g , т.е с отладочной информацией, во-первых увеличивается время компиляции, во-вторых увеличивается размер, делать это абсолютно незачем если потом будет использован strip
и вы не будете серьезно заниматься отладкой

export LDFLAGS="-s"

включит strip при компоновке, хотя лучше задать несколько побольше

export LDFLAGS="-Wl,-O1 -Wl,--as-needed -s"

про значения посмотрите man ld

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

man ld:

-O level
If level is a numeric values greater than zero ld optimizes the output. This might take
significantly longer and therefore probably should only be enabled for the final binary.
At the moment this option only affects ELF shared library generation. Future releases of
the linker may make more use of this option. Also currently there is no difference in
the linker's behaviour for different non-zero values of this option. Again this may
change with future releases.

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

ок, поясню мысль. Не понимаю, что можно оптимизировать на стадии линковки в уже скомпилированной программе. Какие символы видимы, какие нет - это уже в момент компиляции понятно. Инлайнить что-то уже поздно.

В интеловском компиляторе есть IPO, но там компиляция фактически происходит в момент линковки, в GCC этого не происходит.

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

оптимизация при компоновке, символов в секциях, снижение числа relocations, документации мало, можно посмотреть исходники gnu ld

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

ipo в gcc это lto

включается -flto или -fwho-pr

делает то же самое что и -ipo


кстати IPO применялась очень давно КДЕшниками, еще с КДЕ 1

включалось это
configure --enable-final

исходники для каждой библиотеки или программы обьединялись в один файл и компилировались одним вызовом компилятора

Sylvia ★★★★★ ()

>Тогда каким образом правильно указать в последнем случае необходимость связывания именно с динамическими библиотеками?

Библиотеки, собираемые тулзами пострипаны, ./configure && make && make install ставит библиотеки, собранные с -O2 -g и не пострипанные. Отсюда и разница.

P. S.: делая configure && amke && make install, ты превращаешь свою систему в помойку.

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

>ipo в gcc это lto

а, это в 4.4 добавили, прозевал) спасибо

исходники для каждой библиотеки или программы обьединялись в один файл и компилировались одним вызовом компилятора

ну это насколько я понимаю не то же самое, так как в стандартном режиме функции в основном компилируются по-отдельности (у интела еще есть флаг -ip для оптимизации файла целиком)

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

>./configure && make && make install ставит библиотеки, собранные с -O2 -g и не пострипанные.

это по умолчанию, тем не менее большинство собирающих делают

export CFLAGS
export CXXFLAGS
export LDFLAGS

на нужные значения

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

4.5.x

да, не совсем то, но все равно это применялось более 10 лет назад, с тулчейнами в которых даже понятия об LTO еще не было )

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

>Не понимаю, что можно оптимизировать на стадии линковки в уже скомпилированной программе.

call && jmpXX

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

ну во-первых лениво писать это каждый раз)
во-вторых для флагов компоновщика есть LDFLAGS

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

можно просто -s

хотя в мезу недавно накоммиттили, что их линкер скрипт матерился на -s
пришлось -Wl,-s сделать )

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

>CFLAGS не передаются на этапе компоновки

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

естественно это нестандартное поведение и авторам пишущим подобные безобразия надо сказать фи

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

>однако все на откуп авторов программ,

При использовании automake это надо постараться, чтобы LDFLAGS игнорировать.

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

>естественно это нестандартное поведение

по-моему, нестандартное поведение - это вызывать ld вместо компилятора. а если вызывается компилятор, то и флаги ему надо передавать все, иначе мало ли что он там натворит

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

вызывать ld вместо компилятора как раз допустимый вариант, особенно в случае компоновки чего-нибудь хитрого, с указанием startfiles

Sylvia ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.