glibc-2.3.2

мало условий задали,
привели бы вывод ошибок при компиляции этого самого проекта на старом ядре с старыми же glibc

если активно используются thread-ы, думаю, что малой кровью не обойдетесь

nptl и tls нет конечно,
но есть linuxthreads

вопрос не в юзерспейсе, а в ядерной реализации ниток.

2.4 и 2.6 очень сильно различаются в этом плане

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

ошибки зависят от версий компиляторов (на хосте и таргетный кросс) и от наличия --without-headers в вызове crossdev'а.
всю матрицу я ессно не помню, и посмотреть сейчас не могу.
Одна из ошибок про ".if" c неконстантным выражением в асме, другие про неэльвалюе в присваивании. общий смысл таков, что ни веткой 3.x, ни 4.x старые glibc не собрать. Так же как и старые gcc-2.9.x. Для x86. Для ppc якобы всё работает.

Забыл упомянуть маленький нюанс, собранная на ленни первая версия успешно работает и там и там.
Т.е. в принципе решение существует, но дебиан показал себя крайне неудобным для разработки дистрибутивом.
С потоками никаких проблем нет, подозреваю, что в этом заслуга boost'а.

> привели бы вывод ошибок при компиляции этого самого проекта на старом ядре с старыми же glibc

Упс, пропустил.
Уточняю: на старом ядре ничего не строил, ибо говно м. Со старым glibc ничего не строил. Затыка как раз в том, что эту самую glibc свежими компиляторами не построить.
Эмпирически установлено, что самая старая компилябельная glibc - 2.3.4.
Слинкованное с ней на таргете не запускается.

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

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

Проблемы как раз в нужных версиях либ, если ты не понял.

Спасибо, кэп.

API не поменялся, поменялась только реализация. Поэтому если софт не закладывается на нюансы реализации, то проблем быть не должно.

> Спасибо, кэп.

Глупо задавать такие вопросы. Единственный ответ, который хочется дать: "Работай, давай!".

поставь target дистр в виртуальную машину и посмотри как будет жить, зачем самому заниматься изобретением каких-то велосипедов если пока и сам не знаешь в чем проблема ?

Нормальные люди работают так: разрабатывают на чем удобно, а потом идут на build-машину и собирают для нужной платформы, потом тестеры докладывают что не работает. И если вдруг что-то не заработает, то только тогда надо лезть на target платформу и смотреть в чем специфика.

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

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

Счастлив тебе сообщить, что у нас работают нормальные люди.
Мне кажется, "специфику" я описал достаточно ясно.

После исправления пятой ошибки я усомнился в правильности решения патчить сабж до совместимости с современными gcc.
Тем более, что шестая была ошибкой ассемблера, а у нас нет спецов по гнутому ассемблеру.
В любом случае, написание патча для glibc выглядит неадекватной ценой для решения данной задачи.
Тем не менее, приду на работу, выложу последнее сообщение об ошибке.

Собрав libc-2.3.2 новым компилятором, вы не решите свои проблемы. Есть различные подводные камни, в частности уже упомянутая различная реализация threads, в "старом" и новом ядрах. Нормальные разработчики должны внимательно чиать доки и помнить от всех новых фичах libc и писать код который соберётся на старой системе.

>Использовать таргет в качестве платформы разработки меганеудобно.

Зачем вы объединяет платформу разработки и платформу компиляции?

Еще раз повторю. Правильное решение только одно -- держать target систему на отдельной машине или в виртуалке. Разрабатывать и запускать софт на своей машине и отлаживать тоже на своей машине, а в последний момент запускать уже на target'е.

Embedded это тема вообще отдельная. В этом случае у тебя должен быть developer board и/или эмулятор в котором пускаются откомпилированные на машине разработчика бинарники.

Ты невнимательно читал, никаких проблем с потоками нет.
> Зачем вы объединяет платформу разработки и платформу компиляции?
Э... где я такое писал?
Таргет не годится ни как билдер, ни как воркстейшн. Так яснее?

> держать target систему на отдельной машине или в виртуалке
Ещё раз повторю, именно так всё и есть.

> отлаживать тоже на своей машине
Эмулировать таргет на рабочей машине несколько э... трудно.

Embedded был только для примера.

Если и там linux и там linux, то не вижу никаких проблем.

автор этого треда вызывает раздражение.

Проблема на билдере.
Построенное на нём хочет более новый, чем на таргете glibc.

Очень рад, жалко, что не рак жопы.
Есть что сказать по существу - говори.
Нет - присоединяйся к mv, здесь тебе не толксы.

В общем, crossdev я убил своими экспериментами, а из бэкапа машину поднимать очень лениво.
Вот ссылка на багу:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12928
Отличие в том, что при построении 2.3.2 ругается на строки в sigsuspend.s с номерами 6x, а не 8x.

Собственно, запостил для очистки совести - раз обещал. Похоже, проблема не имеет решения с приемлемыми сроками выполнения.

Так естественно собирать по таргет надо родным тулчейном. Проблема по-моему высосана из пальца.

> Так естественно собирать по таргет надо родным тулчейном.
Не обязательно. Собранное под ленни таких зависимостей не имеет. Думаю, дело тут в eglibc, но тем не менее.

> Проблема по-моему высосана из пальца.
Я так не считаю.