Прикладная компиляция с разными версиями gcc [solved]
Программирую под гентой, раньше всегда пользовался компилятором установленным в системе (последняя версия gcc-4.1.2), недавно в связи с выходом c++0x решил перейти на компилятор поновее. Установил gcc-4.3.3-r1.
Смену системного компилятора не делал, оставил системе старую версию.
При компиляции командой
$ g++ -V 4.3.3 a.cpp
выдает:
"g++: ошибка при выполнении '/usr/x86_64-pc-linux-gnu/gcc-bin/4.1.2/x86_64-pc-linux-gnu-gcc-4.3.3': Нет такого файла или каталога"
, хотя x86_64-pc-linux-gnu-gcc-4.3.3 есть в /usr/x86_64-pc-linux-gnu/gcc-bin/4.3.3/.
Почему так, как исправить? Это первый вопрос.
Второй вопрос. Попробовал компилить командами gcc-4.3.3 и g++-4.3.3,
всё отлично работает, но при включении -O3 при выполнении выдает:
/mydir/MyProgram: /usr/lib/gcc/x86_64-pc-linux-gnu/4.1.2/libstdc++.so.6: version `GLIBCXX_3.4.9' not found (required by /mydir/MyProgram)
Как уровень оптимизации может на это влиять, озадачило...
- Для комментирования войдите или зарегистрируйтесь
А если gcc-config'ом
А если gcc-config'ом постоянно переключаться или не вариант?
1) gcc-config, однозначно.
1) gcc-config, однозначно. Настройка компилятора весьма нетривиальна, посему засунули в скрипт.
2) c++0x уже утвердили в качестве нового стандарта? Если нет - писать под него не стоит. Во первых никому не надо нестандартной вещи, во вторых запросто могут поменять что нибудь при стандартизации.
в чем недостаток
А чего я лишаюсь если использую
$ i686-pc-linux-gnu-gcc-4.1.2 myfile.c
и
$ i686-pc-linux-gnu-gcc-4.3.3 myfile.c
?
т.е. если по умолчанию стоит 4.1.2, то вторая команда не даст полный 4.3.3 ?
>>А чего я лишаюсь если
>>А чего я лишаюсь если использую?
less `which gcc-config`
qlist gcc
Компиляторы, мягко говоря, меж собой несовместимы. Потому в комплекте каждого идут свои библиотеки и заголовочные файлы. Все это настраивается установкой соответсвующих переменных окружения. В вашем случае один из компиляторов будет использовать библиотеки другого и возможно возникнут проблемы со сборкой приложения.
Других вариантов точно нет?
Ну если других вариантов нет то придется переключаться. Т.е. делаю emerge - ставлю одну версию, пишу свои проги - ставлю другую версию?
Других вариантов точно нет? А если я захочу разные модули разными версиями компилить? А может наподобии кросскомпиляции сделать?
На счет c++0x, стандарт вроде бы ещё не утвержден, но в этом году должен. Но мне не дождаться, там есть несколько настолько сладких штук, в основном для шаблонов, что я готов пойти на пока нестандартное решение. На данный момент я думаю уже ничего выкидывать не будут, кроме того в gcc из нового стандарта то меньше 30% реализовано пока, а в 4.3 и того меньше.
Цитата:Ну если других
Что за тупняк? (-%Е
% gcc-config --helpТекстовый редактор vi имеет два режима работы: в первом он пищит, а во втором — всё портит.
Тупняк в том что не хочется
Тупняк в том что не хочется каждый раз делать gcc-config, в любой момент можно забыть переключится и т.п., и никакой автоматизации не сделать, потому что вызывать надо из под рута.
sudo поможет
sudo поможет
А-а-а, я уж испугался, что ты
А-а-а, я уж испугался, что ты переустанавливать gcc хочешь. Ошибся.
Ну а для автоматизации есть sudo.
Я, правда, не очень понял, в чём проблема. Я так понял, что gcc просто не собирает. А он обновлялся по руководству с gentoo.org? Почему просто g++ не собирать?
Текстовый редактор vi имеет два режима работы: в первом он пищит, а во втором — всё портит.
Я не обновлялся, сделал
Я не обновлялся, сделал emerge =gcc-4.3.3 только.
Повторю вопросы кратко:
1. g++ -V 4.3.3 - не работает
2. компиляция через g++-4.3.3 работает, но при включенной оптимизации (только) в runtime сообщает о `GLIBCXX_3.4.9' not found
павыф
А зачем так хитро? Почем тупо не переключить весь gcc на 4.3?
Этого уже не знаю.
Текстовый редактор vi имеет два режима работы: в первом он пищит, а во втором — всё портит.
Чего-то ничего не нашел
Чего-то ничего не нашел путного, а работать то надо. И с gcc-config я запарюсь чувствую, и так головняков хватает. В общем решил полностью на 4.3.3 перейти, тупо. Обидно что решения не нашлось :(
>>Чего-то ничего не нашел
>>Чего-то ничего не нашел путного, а работать то надо. И с gcc-config я запарюсь чувствую, и так головняков хватает. В общем решил полностью на 4.3.3 перейти, тупо. Обидно что решения не нашлось :(
1) 4.3.3 имеет ряд проблем со сборкой системы. Тупо перейти не удасться.
2) Вам нужно ГОТОВОЕ решение? - Напишите его. Вы же программист. Когда напишете - посмотрите на его код. Если получится строки четыре - значит с программированием у вас все в порядке. Может тогда вы поймете почему готового решения нет. Рут, к примеру, может автоматом выставлять компилятор из какого нить .башрц в своей хоме. Осталось сформулировать вашу проблему для автоматизации вашего переключения. От чего бы программе самой не знать, каким профилем компилера ей надо собираться? И что? мейк не справится с поставленной задачей?
паыф
Тупо перешёл ещё летом. Да, кое-кто не собирался, пришлось размаскировывать версии поновее. Сейчас проблем не ощущаю.
Текстовый редактор vi имеет два режима работы: в первом он пищит, а во втором — всё портит.
Кхм
Были проблемы при перехаоде с 4.1.2 на 4.2.1. При дальнейшем переходе на 4.3.1 проблем уже не возникло. Всё пересобралось отлаженно и быстро.
Видел (и исправлял) ошибки
Видел (и исправлял) ошибки ещё в январе на ~amd64. Не надо вводить человека в заблуждение, что всё безоблачно - всё-таки это не стабильная ветвь.
У меня единственно koffice
У меня единственно koffice отказался собираться. Встал только после выхода версии от 2009 года. Кстати версия koffice-2 так и не появилась в portage. Даже в overlay его нет.
emerge @koffice — всё есть.
emerge @koffice — всё есть.
Пересобрался, вроде пока всё работает.
Пересобрался, вроде пока всё работает. Вот тока с precompiled headers 4.3.3 вылетает c segfal.
Ничего не понял :)
Если некую инструкцию
Если некую инструкцию записать в каталог пользователя, в некйи файл, к примеру в .bashrс, то при логине этого пользователя произойдет выполнение инструкции. В данном случае при логине рутом система сможет запросто вернуть себе нужный компилятор на место. Один из стандартных способов автоматизации. Можно прописать обертку под емерге, либо алиасом, либо небольшим скриптом. Вообще вариантов реализации масса. Вы точно программист?
Спасибо.
Спасибо. Да, но мне это все не нравится потому что завязано на gcc-config. Это не позволяет работать сразу с двумя версиями. Например запустил я обновление и ставится у меня openoffice, я должен сидеть ждать? Просто увидел я опцию gcc -V <версия> - "использовать <версию> gcc, если она установлена", вот я подумал что можно.
Не думаю, что надо кого то
Не думаю, что надо кого то ждать. Все дело в том что опция действительно может запустить нужную версию гцц. Но собственные библиотеки gcc будет искать скорей всего по переменным окружения.Пока вы не сказали source /etc/profile переменные окружения не меняются. gcc-config переключает профиль "навовсе", тоесть прописывает его в /etc/profile.Переменные окружения считываются 1 раз при логоне, тоесть в разных сессиях они вполне могут быть разными. Посмотрите /etc/env.d/gcc/* на предмет переменных окружения для gcc. Возможно для компиляции при текущем профиле 4.1 сработает нечто такое:
GCC_PATH="/usr/i686-pc-linux-gnu/gcc-bin/4.3.3" gcc -V 4.3.3 ...
или последовательность вызовов
export GCC_PATH= .....
export ....
gcc -V 4.3.3 .....
А вот и решение!
Пишем скрипт (переключаем профиль, делаем source /etc/profile и переключаем его обратно) :
#!/bin/bash
sudo gcc-config 2
source /etc/profile
sudo gcc-config 1
Запуская его под юзером при загрузке получаем второй профиль компилятора для юзера и первый для рута с правильными переменными окружения для каждой версии компилятора.
Спасибо wi!
Ни чего не понимаю...
?! =-O Шо цЭ такЭ?! Зачем переключаться туда-сюда?!
лучше использовать chroot
gcc-config не только правит переменные, но и меняет символьные ссылки (в gcc-config смотрите), что значит влияет на всю систему в целом, а не только текущую сессию.
Вообще то очень давно существует универсальное решение для подобных задач - chroot.
Настраиваем либо копию текущей системы (кстати идеальное решение lvm + snapshot), либо минимальную stage3 + зависимости своего пакета и уже в нем запускаем компиляцию. Не забываем про env-update после перехода в chroot ну и для смены версии gcc - само собой gcc-config. Ну и для вывода файлов из chroot можно всю или часть домашней директории забиндить на реальную - mount -o bind /home/user /chroot/home/user.
P.S. На сколько я понимаю в portage так и делают при любой компиляции, в том числе и если в каком то .ebuild прописана конкретная версия компилятора.