LINUX.ORG.RU

траблы с gcc/binutils


0

1

на работе собираем мы gcc и бинутилс из исходников. с целью прикрутить некоторые собственные патчи. что за патчи, зачем - не знаю, но и не суть. а суть в том, что во время билда в объектник зашиваются пути вида <...>/include. причем часть из них - сетевые по NFS. все хорошо, пока к этим директориям есть доступ (например в нашем отделе) или этих директорий нет вобще (в других отделах). но есть отделы, в которых эти директории видны, но доступа к ним нет. и вот у них билд с использованием этих gcc и binutils рушится. при этом если в этих директориях и есть что-то нужное, оно нужно только во время билда самих gcc/binutils. при дальнейшем их использовании лезть туда не нужно

что можно попробовать предпринять для решения?

> что можно попробовать предпринять для решения?

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

Нужно хотя бы:

1) Платформа сборки

2) Таргет сборки

3) Чем собираете

4) Где находится sysroot/build-sysroot

5) Как именно рушится, на каких этапах

6) Уверенность, что это не местные патчи поломали toolchain есть?

ky-san
()

Сделать, чтобы они были не видны, в явном виде указать системе сборки, что в эти каталоги не лазить, etc.

dn2010 ★★★★★
()

Осилить опции -I, -isystem, -iquote, -B, -dumpspecs, -specs, почитать про переменные окружения типа C_INCLUDE_PATH (всё есть в man gcc) и системы сборки вроде того же make для их автоматической подстановки, и перестать выпендриваться.

Прозреваю быдлокод.

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

Осиливать нужно опции для конфигурации кросс-тулчейна, а именно --with-sysroot & --with-build-sysroot + элементарно specs поправить, если что

ky-san
()

>если в этих директориях и есть что-то нужное, оно нужно только во время билда самих gcc/binutils. при дальнейшем их использовании лезть туда не нужно

Проверьте:

1.Не использует ли GCC или libgcc каких-нибудь из библиотек во время работы?

2.К каким библиотекам прилинковываются собираемые бинарники? Посмотрите при помощи ldd или readelf.

3.У вас specs свой или по умолчанию? Если по умолчанию, не попало ли туда чего лишнего?

И на каком этапе, собственно, рушится билд?

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

>>И на каком этапе, собственно, рушится билд?

на этапе линковки, насколько я могу судить по скудным логам самописной (не моего авторства) системы сборки

3.У вас specs свой или по умолчанию? Если по умолчанию, не попало ли туда чего лишнего?

пока не знаю, что это (щас погуглю), но читая makefil'ы упоминаний похожего не встречал. поэтому рискну предположить что по умолчанию

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

>на этапе линковки,

А с какой ошибкой? И если на этапе линковки, то ошибка, надо полагать, в binutils, а не в GCC.

пока не знаю, что это (щас погуглю)


Вот тут описано:
http://gcc.gnu.org/onlinedocs/gcc/Spec-Files.html

Узнать путь к файлу specs по умолчанию можно так:
echo $(dirname $(gcc -print-libgcc-file-name))/specs

Если этого файла нет, по умолчанию используются встроенные specs, кторые можно вывести так:
gcc -dumpspecs

Можно вывести их в файл specs и отредактировать.


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

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

>да, те, кто исследовал проблему до меня, пришли к такому же выводу

Тогда надо посмотреть, какие именно ошибки выпадают. А сначала попытаться скомпилировать и слинковать Hello, world.

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

проблема осложняется тем, что у меня(/моего отдела) проблемные директории доступны. поэтому для воспроизведения придется привлекать кого-то еще. если бы понять, откуда у них ноги растут и даже хотя бы как в этот список директорию _добавить_, уже было бы проще.

еще одна сложность в том, что сборка идет под специализированную кластерную ОС с помощью специализированной системы сборки, правила для которой генерятся автоматически и ориентированной на специализированное хранилище кода. короче маленький велопарк квадратных колес, который делает ручную сборку даже helloworld'a весьма нетривиальной задачей

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

>проблемные директории доступны

А временно их отмонтировать как-нибудь нельзя? Или хоть каким-нибудь способом организовать песочницу, чтобы GCC в них залезть не мог?

делает ручную сборку даже helloworld'a весьма нетривиальной задачей


А просто собрать его безо всякой системы сборки, вызвав компилятор и ld напрямую?

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

Добавь компилятору опцию -v и -w для make, потом собери вывод. Там будут все команды, сразу увидишь, что куда лезет + сможешь сделать тесты и повторить сборку руками

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

Пока ты не расскажешь, что именно у тебя не так - тебе сложно будет помочь. Пиши на бумажке, фотографируй, варианты есть

ky-san
()
Ответ на: комментарий от geekless

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

marvin_yorke ★★★
() автор топика

так, оказалось, что gcc собран с --with-headers, указывающим в проблемную директорию. думаю что с бинутилс тоже что-то подобное. пойду копать скрипты сборки

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