Разработка для более старых версий и других дистрибутивов.

[wl]

У меня есть проект на C++.
Программа работает на RHEL-4 и на RHEL-5.
Моя рабочая машина - Ubuntu 10.04 (как руки дойдут, обновлю до 11)

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

Пока не получается, в частности из-за более новой версии glibc.
При запуске исполняемого файла получаю ошибку: /lib/libc.so.6: version `GLIBC_2.7' not found

[andrey_p]

Да можно, конечно, - кросс-компиляция, но - это же свой toolchain нужен - от ядра до binutils. Проще в виртуалке поставить нужные дистрибутивы и там компилировать. Да вообще особой проблемы не вижу - пиши, собирай, отлаживай, а там просто перекомпилировать придется (если, конечно, там не урезано все).

[wl]

Да, точно!
Что ж это я - очевидная ж вещь.

Собственно, у меня несколько другая проблема.
Нужна версия FFmpeg поновее (то, что в DAG repo - не подходит, уже старо).
Я вытащил из git-а исходники, скомпилировал, а она ругается, что, мол, компилятор не выровнял переменные в стеке, посему все будет работать очень медленно или вообще навернется - и не жалуйтесь. Попробуйте gcc версии >= 4.2

А на 4-й шляпе стоит gcc 3.4.6. И от него зависит вся система, т.е. просто обновить не получается.
Собираю, вот, из исходников.
Пока жду, решил потрендеть за жиссь спросить, может, есть другой вариант.

[aliftin]

Виртуальная машина это лучший вариант. Может собирать не в ubuntu, а в debian sid? Так или иначе, если вы соберете свою программу со свежим ffmpeg, то где уверенность что не будет проблем на других машинах с ffmpeg из стандартных реп.

[wl]

Уверенность - у меня. Т.к. машин таких ограниченное количество, и ffmpeg туда ставлю тоже я. А они даже к интернетам не подключены.

И тут беседа плавно сменила тему.

У меня и реальная машина есть. Виртуальная машина не поможет, т.к. моя программа работает с железом.

В качестве IDE я использую Eclipse, запущенную на моей локальной убунте.
Файловую систему монтирую с помощью sshfs.
Команда сборки проекта заменена с make на "ssh 192.168.... (что-то там еще) make"
Команда вызова gdb - тоже.

Проблема в том, что тамошний компилятор работает с другой файловой системой, поэтому пути файлов отличаются от тех, что видит Eclipse. Поэтому, когда случаются warning-и и ошибки, эклипсовский парсер ошибок бесполезен, приходится искать их руками.
gdb что-то вообще не запускается.
Remote Systems Explorer тоже победить не удалось.

Netbeans работает, там есть специальная опция path mapping.
Но какая же жуть там со шрифтами. Даже в версии 7.0

[Yurror]

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

[ermak]

Netbeans работает, там есть специальная опция path mapping.
Но какая же жуть там со шрифтами. Даже в версии 7.0

Это проблема JRE (а не NetBeans), для Swing приложений не используется системный рендеринг шрифтов. Вроде нет способа это исправить.