LINUX.ORG.RU

Сборка GCC


0

0

Надо собрать gcc для Freebsd из под linux. Первый этап этой эпопеи - сборка кроскомпилятора прошел успешно. Теперь остался второй этап - сборка нитивнного для bsd компилятора при помощи собранного крос-компилятора. Возникают проблемы с тем, что во время сборки нативного gcc у процесса сборки постоянно чешуться руки что-то собрать и начать это использовать, что увы невозможнло так как целевая архитектура отличается от той на которой собирается компилятор (то что собралось для bsd не может запуститься под linux). Инфы по этому процессу наковырять неудалось, может кто поделиться идеей?

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

melkor217 ★★★★★
()

нативный, надеюсь, не в той же директории собираешь, что и кросс?

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

Понадобилось за тем что GNAT в бзде под x86_86 нету и собирать эту дрянь надо самому.

Нет Я естесно собираю в другой директории.

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

Идея выковыревать glibc из скриптов crosstool мне мягко говоря противна. Может быть менее эротичные методы предложите, а камасутру на потом?

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

> Понадобилось за тем что GNAT в бзде под x86_86 нету и собирать эту дрянь надо самому.

> Может быть менее эротичные методы предложите, а камасутру на потом?

Бсдя? Кросс? Ада? Я думаю, все остальные методы менее эротичны. Типа использовать Линукс и GNAT2009 из соседней новости.

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

Ну вот приперло некоторых (не меня) на бзде и под адой и для 64 бит писать и нужен туда компилер... вот и парусь с этой хренью, толком не могу понять что надо сделать чтобы гцц сам себя скомпили под другую архитектуру ну хотябы в формате простого сишного компилера, не то чтоб аду прикручивать, хотя она представляет главный интерес конечно. /Если у кого есть идеи делитесь плиз.

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

+1 за остроту ума и сообразительность! Только вот для повышения вашей эрудиции спешу сообщить, что ADA во фряхе в её штатном компилере ОТКЛЮЧЕНА, её просто нет, а чтоб собрать компилятор для АДА нужен компилятор с поддержкой АДА, круто одним словом.

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

Специально для вас:
/usr/ports/lang/gnat-gcc43# make
===> gnat-gcc-4.3.2_2 is only for i386, while you are running amd64.
*** Error code 1

Stop in /usr/ports/lang/gnat-gcc43.

Как говориться, иногда лучше есть семечки... Еще идеи есть?

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

> gnat-gcc-4.3.2_2 is only for i386, while you are running amd64.

Пересобери пакет из Fedora, или возьми GNAT 2009 для Darwin, или еще что-нибудь заведомо собирающееся.

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

Пакеты для Linux вообще-то говоря к FreeBSD НЕ ПОДХОДЯТ! Насчет Darwin есть сомнения которые Я проверю (ядро-то РАЗНОЕ). И сам GCC заведомо собирается если есть нужное окружения, а его нет.

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

> Пакеты для Linux вообще-то говоря к FreeBSD НЕ ПОДХОДЯТ!

К.О. ITT

Понятно, что не подходят - но их можно взять за основу своей сборки.

> Насчет Darwin есть сомнения которые Я проверю (ядро-то РАЗНОЕ)

Вот уж ядро для компилятора - дело десятое.

> И сам GCC заведомо собирается если есть нужное окружения, а его нет.

У GCC этих "нужных окружений", в которых он собирается - десятки.

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

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

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

А что у GNAT2009 который доперепиленный кусок gcc зависимостей в окружении будет сильно меньше? А потом Ч таких зависимостей знаю всего 5 - binutils, libc, gmp, mprf + стандартное сборочое окружение (make, работающий cc и пр хрень котороя есть в любой системе где можно хоть что-то скомпилить). Что-то я десятка-то и не насчитал.

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

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

Ну, если ты так глубоко разбираешься в вопросе, я за тебя спокоен.

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

> Ну вот приперло некоторых (не меня) на бзде и под адой и для 64 бит писать и нужен туда компилер...

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

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

>Типичный FreeBSD-хам :)

Спасибо, обязательно учту ваше замечание.

>Сильно сомневаюсь в умственных способностях "некоторых". Если ты такое чудо все же соберешь, вы огребете кучу багов в самые неподходящие моменты.

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

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

> Да проблемы может и будут, но они будут с любым чудом техники.

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

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

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

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

Неудачник. Развлекайся http://www.sigada.org/education/gnapplets/connect_four.html

ЗЫ самый нормальный способ это собрать из i386 фряшного окружения toolchanin для amd64. Такой тазик хотя бы можно в чруте/джейле из amd64 пускать, правда, со страшными глюками некоторых программ.

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

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

По теме есть вопрос: а как вообще впервые собирается компилятор под новую архитектуру? Сначала собирается кросс-компилятор, как это работает понятно. Но вот как с его помощью собрать ГЦЦ под другую архитектуру? Эксперимент показал что при сборке ГЦЦ только с С с определенного момента ГЦЦ пытается собрать себя самим собой что увы неполучается. Я понимаю что не умею готовить этого зверя, но ведь должен быть рецепт!

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

Ты спросил "как собрать gcc под фрю" и я тебе ответил что он там уже есть. А ты начал хамить. Учись правильно задавать вопросы.

Обращение на "ты" не является признаком хамства и неуважение. А вот демонстративное "выканье" с маленькой буквы не делает тебя образцом вежливости.

> Но вот как с его помощью собрать ГЦЦ под другую архитектуру?

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

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

Ну вот опять неграмотные ответы. Читайте внимательно топик - там проблема описана вполне конкретно и вопросы заданы вполне правильно. Я не спрашиваю "как собрать gcc под фрю" я спращиваю как собрать gcc под фрю из ПОД ДРУГОЙ СИСТЕМЫ С ДРУГОЙ АРХИТЕКТУРОЙ, а это соверщенно иная задача. Просто берешь и запускаешь НЕ работает. Почему мне уже надоело Вам объяснять, не можете Вы этого понять ну и ладно.

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

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

http://www.nongnu.org/thug/cross.html http://www.gentoo.org/proj/en/gentoo-alt/bsd/fbsd/

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

Вы разницу между "кросс-компилятором" и "компилятором собранным под целевую архитектуру" понимаете? по вашим ссылкам видимо не пинимаете и понять не хотите. Кросс-компилятор который из под linux генерирует бинарники для FreeBSD я уже давным давно собрал. Проблема в том, неполучается собрать в linux компилятор под и для BSD.

Совсем на пальцах: --target=x86_64-pc-freebsd7 удачно собирается и работает, --host=ч86_64-pc-freebsd7 НЕ собирается так как на определенном этапе gcc хочет компилировать себя только что собранными бинарниками (а они для другой архитектуры) и процесс обрывается. Это происходит даже в случае указания --disable-bootstrap при конфигурации!

Все что Вы тут насоветовали относиться к --target=x86_64-pc-freebsd7, иными словами не по теме.

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

Так ты попроси у чувака его сборку. Я так и не понял работает она у него или глючит с binutils.

Я бы попробовал собрать, но после двух часов оно у меня так и не собралось в kvm и я забил.

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

--host=x86_64-pc-freebsd7 может быть использован только на freebsd, вообще --host - на чем собираем сам gcc (это же не freebsd), --build - на чем данный gcc должен работать (вот тут уже может быть freebds), --target - для чего генерировать код.
Т.е. --host=x86_64-pc-freebsd7 рассматривается как плпытка сборки 
native gcc на самом freebsd, тут разрешены любые попытки использовать самого себя.

Обычно --build совпадает c --host, в данном случае должен совпадать с target.

Я пару лет назад перетаскивал gnat под допотопный CYGWIN, порядок был следующий:
- устанавливаем исnочники binutils (как же без него) и gcc
- тырим /usr/include и либы с CYGWIN (потребуются при конфигурировании)
- собирам кросс-компилятор под CYGWIN и проверяем его работоспобоность
  (т.е. собранные программы выполняются)
- собираем выриант который должен работать на самом CYGWIN (--build)
- перетаскиваем все на CYGWIN и допиливаем

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

Вот про допиливае это Вы в точку, большииим таким напильником пилим, пилим, пилим и так пока не затошнит.

Только для сборки при помощи кросс-компилятора нужно задавать именно --host а не --build.

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

Каждый ищет путь посложнее. Сборка произвольной программы и gcc по сути несколько отличаются. Не надо переносить опыт сборки простой программы на компилятор. Пользуюсь фиговой тучей самосборных кросс-компиляторов для различных архитектур и ОС, ну нет там проблем если читать документацию по сборке. Я свой путь для CYGWIN-а прошел успешно за 3 дня (ну многовато было проходов для чистовой ревизии финальной ОС).

If build, host, and target are all the same, this is called a "native". If build and host are the same but target is different, this is called a "cross". If build, host, and target are all different this is called a "canadian" (for obscure reasons dealing with Canada's political party and the background of the person working on the build at that time). If host and target are the same, but build is different, you are using a cross-compiler to build a native for a different system. Some people call this a "host-x-host", "crossed native", or "cross-built native".

Вот закончится перенос и будет --host таким как нравится.

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

Сорри, что-то я свои старые config.status не найду, может и, правда, --build и --host переставил.

There are three system names that the build knows about: the machine you are building on ("build"), the machine that you are building for ("host"), and the machine that GCC will produce code for ("target"). When you configure GCC, you specify these with `--build=', `--host=', and `--target='.

--build вообще задавался?

Specifying the host without specifying the build should be avoided, as `configure' may (and once did) assume that the host you specify is also the build, which may not be true.

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

Собственно я веду речь об этом: >If host and target are the same, but build is different, you are using a cross-compiler to build a native for a different system. Some people call this a "host-x-host", "crossed native", or "cross-built native" И при построении такого компилятора возникают некоторые проблемы.

Да --build соответствовал системе на которой происходит сборка --host соответствует системе на которой будет даботать компилятор --target системе для которой он будет генерировать код. При компиляции crossed native компилятора для АДЫ на определенном этапе --build подменяется значением из --host в результате процесс сборки разваливается. Для голого С компилятора такое происходит на момент сборки lubmudflap, и полагаю можно это обойти и очень -таки просто.

Подробности как это может быть сделано с комментариями могут быть найдены здесь http://waste.corolla.ath.cx/doc/gnatport-doc-release/ (Описывает человек которому удалось собрать GNAT для 65 битной фряхи, и его компилятор вроде работает. true_admin приводил ссылку на его переписку.) Повторить этот процесс под линукс пока не пробывал, но уверен что нюансы будут.

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

Проблемы могут быть, например, следующие:
- если машина 32-битная, то 64 бита по умолчанию нормально 
  не подключаются, пока соответствующий enable для bfd не укажешь,
  как-то особо не встречал бинари поддерживающие такое прилично 
  по default-у
- да из-за API-эффектов лучше mudflap и ogmp держать в своем дереве,
  существенно упрощает таск между компьютерами
- в последних релизах gcc указание на необходимость gnat и adalib
  указываются отдельно (хотя, конечно, нужно и то, и то)
- API-библиотек ползет, поэтому компиляция библиотеки 
  GNAT-компилятором другого релиза может выдавать идиотские ошибки,
  иногда достаточно пофиксить один файл, но обычно грабли шире; 
  вот не помню в каком релизе это было, даже не совпадали форматы
  ALI-файлов;
- вообще gnat "не любит" "кросс" режим, это заключается, например, 
  в том что скрипты для тестирования GNAT (acats-тесты) в кросс 
  режиме не особо поддерживаются
- сами acats-ы тоже как-то не особо активно меняются в основном
  дереве gcc в соответствии с изменением стандарта ADA

Учитывая сие, если релиз GNAT источников и локальный GNAT имеют различные релизы, то предпочитаю построить native 
bootstrap-компилятор из источников, существенно упрощает танцы 
с бубном.

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

Спасибо учту и на выходных буду изобретать бубен, уже просто интересно заставить все это заработать.

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