Linux: контролирует, где `ld` ищет объектные файлы .o? - PullRequest
5 голосов
/ 30 марта 2011

Хорошо, вот такая ситуация: я пытаюсь использовать более старое программное обеспечение: отлично работает на Ubuntu Lucid, не работает на Natty.

Итак, я strace d вокруг немного, и получается, что это программное обеспечение вызывает ld, и ld в конечном итоге дает сбой с:

.../ld: crt1.o: No such file: No such file or directory

... да, старый файл crti.o отсутствует ошибка :) Однако я хотел бы задать вопрос в более общих выражениях ...

Дело в том, что это "автономный" (старше) ld здесь, и когда я запускаю .../ld -verbose | less, я получаю:

...
SEARCH_DIR("/usr/local/lib"); 
SEARCH_DIR("/lib"); 
SEARCH_DIR("/usr/lib");
...

Теперь дело в том, что:

  • На Lucid crt1.oв /usr/lib/crt1.o
  • На Натти, crt1.o в /usr/lib/i386-linux-gnu/crt1.o

... поэтому не удивительно, почему crt1.o не может быть найдено, я полагаю.Кажется, все, что мне нужно сделать, это сказать ld искать crt1.o в /usr/lib/i386-linux-gnu, но как мне это сделать?

Я думал, что смогу использовать опцию -L, но man ld говорит:

to link a file "hello.o":

    ld -o <output> /lib/crt0.o hello.o -lc

  This tells ld to produce a file called output as the result of linking
  the file "/lib/crt0.o" with "hello.o" and the library "libc.a", which
  will come from the standard search directories. 
...

-L searchdir
--library-path=searchdir
  Add path searchdir to the list of paths that ld will search for
  archive libraries and ld control scripts.

... означает, что '-L' повлияет на то, где мы ищем "libc.a "(в примере с человеком) - но не для объектных файлов.

Я бы на самом деле предпочел переменную окружения для этого, но я пробовал и LD_PRELOAD_PATH, и LD_LIBRARY_PATH безрезультатно (я думаю, они связаны с "общими объектами", и эти .o файлыне один из тех).

Кто-нибудь знает, существует ли переменная окружения (предпочтительно - или, если нет, опция командной строки для ld), которая будет контролировать, где ld ищет .o объектные файлы?

В качестве примечания, я думаю, я мог бы просто использовать символическую ссылку /usr/lib/i386-linux-gnu/crt1.o в /usr/lib/, но я бы лучше использовал переменную окружения, если она существует ... Если нет, есть ли другие возможные решения дляэтот?

Заранее благодарен за любые ответы,
Приветствия!

РЕДАКТИРОВАТЬ: возможно, уместно: Даниэль Кегель - - с проблемами новичка - sysroot: "ld: не может открыть crt1.о "

Ответы [ 4 ]

7 голосов
/ 30 марта 2011

ОК, после некоторого возни, я думаю, что мне удалось решить мою первоначальную проблему ( хотя обратите внимание, что исходный вопрос по-прежнему тот же, что и принятый ответ ):

LIBRARY_PATH=/lib/i386-linux-gnu:/usr/lib/i386-linux-gnu:$LIBRARY_PATH myprogram --args..

Вот то различие, которое я должен помнить:

  • LD_LIBRARY_PATH используется, чтобы «помочь» исполняемому файлу библиотеки поиска, когда он запущен (то есть загрузка, LD_)
  • LIBRARY_PATH помогает gcc, g++ и компания находит библиотеки, на которые ссылается аргумент -l (например, -ldl, то есть libdl, что также было проблемой в моем случае; см. man g++ больше на LIBRARY_PATH)

Так как myprogram вызывал g++, ld и тому подобное, и они не могли найти библиотеки во время компиляции - добавление аргумента LIBRARY_PATH, похоже, исправило g++ / ld поведение, и поэтому у меня больше нет проблем (даже с crt1.o!) с myprogram .. Надеюсь, это будет продолжаться :)

Спасибо всем за помощь,
Ура!

4 голосов
/ 30 марта 2011

ld вообще не использует путь поиска для .o файлов - вы должны передать ему полный путь (как в примере, приведенном в руководстве).Так что нет, нет способа изменить путь поиска, который он использует для поиска .o файлов.

В общем случае ld не следует вызывать напрямую - например, вы обычно вызываете gccвместо этого, чтобы сделать ваши ссылки.Я бы сказал, что это программа, вызывающая ld, которая здесь виновата.

1 голос
/ 15 августа 2014

Вы также можете использовать --sysroot:

   --sysroot=dir
       Use dir as the logical root directory for headers and libraries.  For example, if the compiler normally searches for headers in /usr/include and libraries in /usr/lib, it instead searches
       dir/usr/include and dir/usr/lib.

       If you use both this option and the -isysroot option, then the --sysroot option applies to libraries, but the -isysroot option applies to header files.

       The GNU linker (beginning with version 2.16) has the necessary support for this option.  If your linker does not support this option, the header file aspect of --sysroot still works, but the
       library aspect does not.

!!! => GNU linker (начиная с версии 2.16) имеет необходимую поддержку для этой опции.

1 голос
/ 30 марта 2011

если это машина x86_64 (я так думаю), то вы должны убедиться, что у вас установлен libc6-dev (я думаю, что другой crt1.o - это файл libc6-dev-i386, ЕСЛИ natty переименовывает 32-битные папки libs (on предыдущие выпуски его / usr / lib32) ....

если вы компилируете для 32-битной системы и получаете эту ошибку ... это должно быть ошибкой в ​​gcc / g ++; попробуйте указать путь с опцией -B

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...