arm gcc, кто сам пробовал собирать? Опции

[federal]

Кто нибудь сам собирал gcc?

Всегда используют кросс компилятор. Да, для разработки этого достаточно.
Но, наверное, у многих рано или поздно возникало желание заиметь на отладке родной gcc.

Теперь вопрос, как его собрать?

Гуглил достаточно много, конкретных статей не нашел как это сделать. Много статей именно про кросс тулчейн.

Нашел, что при сборке тулчейна --target должен быть равен --host. А --build = той системе, где происходит сборка.

Хотел узнать у сообщества, как мне собрать такой gcc для арма? чтобы компилятор и запускался на арме и генерировал код для себя же, т.е. для арма.

Можно ли собрать такой компилятор при помощи CodeSourcery?

--
С уважением

[federal]

xor.kruger, спасибо за совет. Книгу читал.
Как кросс gcc собрать - тут все прозрачно и понятно.

вопрос именно в том, что для нативного gcc собирать glibc надо?
вообще, по логике, не нужно, ибо придется кроме gcc пересобирать всю систему.

мне так же не понятно, есть CodeSourcery, при кросскомпиляции он линкуется с либами(glibc и т.д.), которые идут вместе с CodeSourcery.
на целевой платформе glibc может быть другой(у меня другая).
обычные user-space приложения, собранные при помощи CodeSourcery на целевой плате запускаются и никаких ошибок.

кросскомпилирую binutils, когда --target равен --host, компилирую успешно.


Сообщение отредактировал federal - Oct 31 2013, 11:27

[Tarbal]

xor.kruger, спасибо за совет. Книгу читал.
Как кросс gcc собрать - тут все прозрачно и понятно.

вопрос именно в том, что для нативного gcc собирать glibc надо?

libc.so в обоих случаях используется тот же самый, потому как он динамически линкуемый.
Для статической линковки libc.a надо указать ключ при компиляции апликации.

у кросс компилятора свой glibc
на целевой плате - свой

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

[federal]

libc.so в обоих случаях используется тот же самый, потому как он динамически линкуемый.
Для статической линковки libc.a надо указать ключ при компиляции апликации.

так оно и есть

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

я тоже так считал, да и считаю...
но на деле не совсем так. объясню почему.

вы можете поставить CodeSourcery, иметь из целевой фс либы, скажем, из /usr/lib, но не иметь glibc.
и вы удачно скомпилируете приложение, явно компилятору не указывая, где ваш целевой glibc лежит. Такой фокус не проходит, скажем, с pthread. А вот с glibc проходит. И вы успешно запустите ваше приложение.

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