От чего зависит моя программа, скомпилированная с помощью gcc?
Я пытаюсь понять зависимости программы на C и постепенно понимаю, что gcc main.c -o main скрывает множество деталей.
Вот мой эксперимент (ubuntu-wsl-x64):
Как видите, моя программа связана с
- GNU libc (по символической ссылке
libc.so.6) - Компоновщик GNU (
ld-linux-x86-64.so.2) - Странная динамическая библиотека (
linux-vdso.so.1)
Насколько я понимаю, linux-vdso.so.1 будет реализовывать определенный API libc для повышения скорости определенных системных вызовов.
Вопросы:
- Почему
linux-vdso.so.1еще не включен в libc? - Почему
ldдинамически связан с моим исполняемым файлом? Используется ли он во время выполнения? - Насколько я понимаю, моя программа также должна зависеть от
libgccиcrt0, связаны ли они статически? - Должен быть скрыт
-I, чтобы программа могла видеть заголовочный файл libc. Я прав? Я так, где они? - Я упускаю что-то еще?
Спасибо, добрые незнакомцы.
«Он используется во время выполнения?» Я думаю, что это часть механизма динамического связывания.
Привет, Бармар, я буду иметь это в виду. Тем не менее, в этом случае маркированный список суммирует изображение.
«Я думаю, что это часть механизма динамического связывания». Конечно, но если это часть этапов набора инструментов, зачем связывать его с исполняемым файлом?
Включение его в текстовую форму по-прежнему экономит нам ответы и время, если мы хотим воспроизвести и поэкспериментировать, чтобы наш ответ был красивым и блестящим. В таком случае нам придется перепечатать ваш текст. Конечно, печатать не так уж и много, но это все равно дополнительная работа для потенциально множества других полезных людей, которых вы могли бы сэкономить, приложив лишь немного дополнительных усилий.
Это ld загрузчик исполняемого файла, а не компоновщик.
Конечно, но если это часть этапов набора инструментов, зачем связывать его с исполняемым файлом? - динамическое связывание происходит во время выполнения. Отсюда «динамический».
@StasSimonov Не точно: linux.die.net/man/8/ld-linux
@EugeneSh Я хочу избежать путаницы.
Ответ на ваш вопрос №5: «Да, стоит несколько книг». Начните с компоновщиков и загрузчиков (Джон Левин) и стандартной библиотеки C (П.Дж. Плаугер). Обе книги немного устаревшие, но по сути правильны и хорошо написаны.
Добавьте опцию -v при компиляции. Он сообщит, какие команды выполняются и их аргументы. За кулисами происходит много всего.
Пожалуйста, отредактируйте свой вопрос, чтобы задать одну вещь; вопросы о переполнении стека должны задавать один вопрос, а не несколько.
@zwol ""да - стоит несколько книг" хе-хе, ты абсолютно прав! Когда-нибудь я туда доберусь. Спасибо за рекомендацию.
@TylerH Это один вопрос: что скрывает gcc? Я разложил свой вопрос на подвопросы, чтобы помочь аудитории понять, что я имею в виду. Если это имеет смысл.
@JonathanLeffler хорошая идея. Спасибо !
Ответы 1
Как видите, моя программа связана с
- GNU libc (через символическую ссылку libc.so.6)
Да.
- Компоновщик GNU (ld-linux-x86-64.so.2)
Нет. Это не компоновщик GNU (ld). Это динамический компоновщик Linux. Он служит стандартным загрузчиком программ ELF в Linux. Для запуска каждого исполняемого файла ELF необходим такой загрузчик.
- Странная динамическая библиотека (linux-vdso.so.1)
Вроде, как бы, что-то вроде. «vdso» — это инициализм «виртуального динамического общего объекта». Именно этот параметр предоставляется каждому процессу ядром Linux, и стандартная библиотека C использует его для различных служб ядра. Он не входит в состав libc, поскольку по сути является частью ядра.
- Насколько я понимаю, моя программа также должна зависеть от libgcc и crt0, они связаны статически?
Некоторые программы, скомпилированные с помощью GCC, зависят от libgcc. Другие этого не делают. Это зависит от программы. libgcc может быть скомпонован статически - в GCC для этого есть опция командной строки - но если вы не просили об этом, то, вероятно, это не так.
Я не знаю, что такое crt0, может быть это: https://en.wikipedia.org/wiki/Crt0? Насколько мне известно, это не представляет собой отдельную общую библиотеку, поэтому ldd не буду вам об этом рассказывать.
Должен быть скрыт
-I, чтобы программа могла видеть заголовочный файл libc. Я прав? Я так, где они?
Нет, вы не правы. GCC имеет путь поиска по умолчанию для включаемых файлов, который включает заголовки стандартной библиотеки, с которой он интегрирован. Вы используете опцию -I для добавления каталогов в этот путь поиска, но она вам не нужна для заголовков стандартной библиотеки или для других, установленных по этому пути (и как было бы больно, если бы вы это сделали!). Если вы спросите, Gcc сообщит вам, какой путь поиска используется по умолчанию.
- Я упускаю что-то еще?
Вероятно, многое, учитывая характер конкретных поставленных вопросов. Трудно сказать, какие из них действительно могут вас заинтересовать в этом контексте, и, вероятно, невозможно вписать их в рамки SO-ответа.
Вы можете использовать параметр -v для gcc, чтобы увидеть путь поиска (по умолчанию) для включаемых файлов («скрытые» параметры -I), а также многое другое.
Это очень полезно. Я понимаю, что мой вопрос открыт. По моему опыту, такие знания трудно приобрести. Так что большое спасибо, что нашли время.
Пожалуйста, публикуйте код, данные и результаты в виде текста, а не скриншотов (как форматировать код в сообщениях ). Почему мне не следует загружать изображения кода/данных/ошибок? idownvotedbecau.se/imageofcode