Зашел спор, в котором аргументов кроме как "Я так думаю" и "Вроде где-то видел" у меня нет. Суть: при линковке lib файлов к проекту, в код программы попадают только те функции, которые не вызываются в коде или вапще все из данного либника? Если внутри функции сродержащейся в либнике есть вызов другой функции из этой же библиотеки, то в либфайле содержится список функци от которых завивисит данная или опять же надо включать в код "на всякий случай" все?
Здравствуйте, gybson, Вы писали:
G>Зашел спор, в котором аргументов кроме как "Я так думаю" и "Вроде где-то видел" у меня нет. Суть: при линковке lib файлов к проекту, в код программы попадают только те функции, которые не вызываются в коде или вапще все из данного либника? Если внутри функции сродержащейся в либнике есть вызов другой функции из этой же библиотеки, то в либфайле содержится список функци от которых завивисит данная или опять же надо включать в код "на всякий случай" все?
Только те, что вызываются. Ничего лишнего не включается. Легко проверить, посмотрев длину либов и длину своих ехешников. Возьми сначала "пустой" майн, а потом синус вызови и посмотри разницу. Если в либа включалась вся — длина была бы одинакова.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, LaptevVV, Вы писали:
LVV>Только те, что вызываются. Ничего лишнего не включается. Легко проверить, посмотрев длину либов и длину своих ехешников. Возьми сначала "пустой" майн, а потом синус вызови и посмотри разницу. Если в либа включалась вся — длина была бы одинакова.
Строго говоря, это зависит от самого линкера. Не помню уже деталей (давненько это было), но не раз слышал, что какой-то борландовский линкер прилинковывал все целиком.
Но современные линкеры наверняка достаточно умны для того, чтобы линковать только то, что дейстмительно используется.
Здравствуйте, Bell, Вы писали:
B>Строго говоря, это зависит от самого линкера. Не помню уже деталей (давненько это было), но не раз слышал, что какой-то борландовский линкер прилинковывал все целиком.
Это, наверное, было ОЧЕНЬ давно? B>Но современные линкеры наверняка достаточно умны для того, чтобы линковать только то, что дейстмительно используется.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
B> Строго говоря, это зависит от самого линкера. Не помню уже деталей (давненько это было), но B> не раз слышал, что какой-то борландовский линкер прилинковывал все целиком. B> Но современные линкеры наверняка достаточно умны для того, чтобы линковать только то, что B> дейстмительно используется.
The /OPT option controls the optimizations that LINK performs during a build. Optimizations generally decrease the image size and
increase the program speed at a cost of increased link time.
REF | NOREF
/OPT:REF eliminates functions and/or data that are never referenced while /OPT:NOREF keeps functions and/or data that are never
referenced.
LINK removes unreferenced packaged functions by default. An object contains packaged functions (COMDATs) if it has been compiled
with the /Gy option. This optimization is called transitive COMDAT elimination. To override this default and keep unreferenced
COMDATs in the program, specify /OPT:NOREF. You can use the /INCLUDE option to override the removal of a specific symbol.
If /DEBUG is specified, the default for /OPT is NOREF (otherwise, it is REF), and all functions are preserved in the image. To
override this default and optimize a debugging build, specify /OPT:REF. The /OPT:REF option disables incremental linking.
You have to explicitly mark data as a COMDAT; use __declspec(selectany).
If /OPT:REF is specified, /OPT:ICF is on by default. If you want /OPT:REF but not /OPT:ICF, you must specify the following:
link /opt:ref /opt:noicf
Specifying /OPT:ICF does not activate the /OPT:REF option.
...
Не знаю, не знаю. в BCB каждый день че-нить для студентов проверяю — никаких метров в обычных консольных приложениях нет. Нормальный размер пару-тройку десятков кил, не больше.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Библиотека (.lib-файл в DOS/Windows, .a-файл в UNIX) — это просто сборище объектных файлов (.obj, .o), единственно для удобства обращения и для исключения некоторой повторяющейся в них информации объединенных "под одной крышей". С этой точки зрения и относится к ним сборщик.
А вот правила участия объектных файлов в сборке могут различаться. Иногда все тело объектного файла "вытягивается" по всякой ссылке (сборка на уровне объектных модулей), иногда нет (сборка на уровне функций/объектов). Теоретически, в последнем случае объектный файл должен быть устроен более тонко. Зато, в первом случае возможна ситуация, когда излишний код, попавший в сборку, "тянет" за собой другие модули, хотя они и не нужны, и т. д.
Я понимаю, что включается только то, что надо. Вопрос был еще и такой: "А знает ли линкер точно, что надо включить, чтобы работали функции подключенные из библиотек?". С функциями описанными в исходниках вопросов нет, там все ясно, а вот есть ли список зависимостей для функция находящихся в библиотеках, во всех ли библиотеках?
Здравствуйте, gybson, Вы писали:
G>Я понимаю, что включается только то, что надо. Вопрос был еще и такой: "А знает ли линкер точно, что надо включить, чтобы работали функции подключенные из библиотек?". С функциями описанными в исходниках вопросов нет, там все ясно, а вот есть ли список зависимостей для функция находящихся в библиотеках, во всех ли библиотеках?
Обычно в объектном модуле (а вовсе не в библиотеке) есть такая структура — словарь внешних символов. Там-то и прописываются все имена вызываемых функций.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Re[4]: Как линкер линкует либы?
От:
Аноним
Дата:
17.02.04 08:25
Оценка:
G>>Я понимаю, что включается только то, что надо. Вопрос был еще и такой: "А знает ли линкер точно, что надо включить, чтобы работали функции подключенные из библиотек?". С функциями описанными в исходниках вопросов нет, там все ясно, а вот есть ли список зависимостей для функция находящихся в библиотеках, во всех ли библиотеках? LVV>Обычно в объектном модуле (а вовсе не в библиотеке) есть такая структура — словарь внешних символов. Там-то и прописываются все имена вызываемых функций.
Вопрос в том, есть ли там ещё и словарь внутренних символов.
А что он делает со static функциями.
По идее их имена линкеру вообще не видны, а для их вызова компилятор может использовать какие-то упрощённые конструкции (снижать степень косвенности).
А как там сейчас обстоит дело с определением адресов функций?
Помнится в ДОС была специальная таблица по которой пробегал загрузчик и правил адреса в коде загруженного exe-шника? Или я не прав?
А как сейчас? Править загруженные exe-шники вроде нельзя — файлы мапятся в память и под исправленные страницы надо создавать копии. А делать дополнительный уровень косвенности (вызовы через таблицу) — тоже не интересно.
Или сейчас все программы линкуются для работы по фиксированному адресу?
А как же тогда dll, точнее вызовы функций внутри dll?
