Как установить gcc 4.3 на Fedora 12?

http://www.linuxquestions.org/questions/fedora-35/uninstalling-gcc-4-4-in-fedora-12-a-800154

если будете собирать из исходников

./configure --prefix=/usr/local/gcc-4.3
make
make install


все будет установлено в пределах указаного префикса,
перед сборкой софта старой версией можно будет сделать так


export PATH=/usr/local/gcc-4.3/bin:$PATH

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

Спасибо!

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

А установить те переменные, которые Вы советовали в параллельной теме — недостаточно?

можно и те,
но нужно будет сделать симлинки

допустим в /usr/local/bin

ln -s /usr/local/gcc-4.3/bin/gcc /usr/local/bin/gcc-4.3
ln -s /usr/local/gcc-4.3/bin/g++ /usr/local/bin/g++-4.3

Уже скачиваю исходники вот так:

svn co svn://gcc.gnu.org/svn/gcc/tags/gcc_4_3_4_release gcc

Получается, у меня gcc-4.4 будет компилировать gcc-4.3? А оно точно сработает? :))

> но нужно будет сделать симлинки

А alternatives делает ровно это? Или что-то другое?

Я сейчас вижу, что /usr/bin/gcc это у меня бинарник. Оно заменит его на симлинк?

Или лучше на заморачиваться с alternatives? Если считать, что потребность использовать 4.3 у меня будет возникать редко, то достаточно иметь Ваши симлинки и устанавливать переменные?

Федора уже жжет , Debian Squeeze:
$wajig search gcc-4.
gcc-4.4 - The GNU C compiler
gcc-4.4-base - The GNU Compiler Collection (base package)
gcc-4.3 - The GNU C compiler
gcc-4.3-base - The GNU Compiler Collection (base package)
gcc-4.1-base - The GNU Compiler Collection (base package)
gcc-4.1-locales - The GNU C compiler (native language support files)
gcc-4.1-multilib - The GNU C compiler (multilib files)
gcc-4.1-source - Source of the GNU Compiler Collection
gcc-4.1 - The GNU C compiler
gcc-4.3-locales - The GNU C compiler (native language support files)
gcc-4.3-multilib - The GNU C compiler (multilib files)
gcc-4.3-source - Source of the GNU Compiler Collection
gcc-4.4-locales - The GNU C compiler (native language support files)
gcc-4.4-multilib - The GNU C compiler (multilib files)
gcc-4.4-source - Source of the GNU Compiler Collection
gpc-4.1-doc - Documentation for the GNU Pascal compiler (gpc)
llvm-gcc-4.2 - Low-Level Virtual Machine (LLVM), C/C++ front-end
gcc-4.1-doc - documentation for the GNU compilers (gcc, gobjc, g++)
gcc-4.2-doc - documentation for the GNU compilers (gcc, gobjc, g++)
gcc-4.3-doc - documentation for the GNU compilers (gcc, gobjc, g++)
gcc-4.4-doc - documentation for the GNU compilers (gcc, gobjc, g++)

Исправить «пакет»

да

последний релиз 4.3.5
ftp://ftp.fu-berlin.de/unix/languages/gcc/releases/gcc-4.3.5/gcc-4.3.5.tar.bz2

я бы еще добавила к ./configure ключик --enable-languages=c,c++
чтобы не собирать лишнее

alternatives будет не в курсе про установленый вручную компилятор

для редких случаев можно не делать симлинки и просто переустановить PATH

> я бы еще добавила к ./configure ключик --enable-languages=c,c++

чтобы не собирать лишнее

Поздно, уже компилится. Спасибо большое за подсказки, Вы отличный специалист. И форум у вас тут хороший :)

> последний релиз 4.3.5

Видел, но мало ли что? Выбрал для симметрии 4-3-4 :) Всё равно может ещё даунгрейдить придётся...

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

> что в предыдущей теме уже написали что патчить.

Так у меня ещё образовался пакет, который нужно патчить, но сильнее. Поэтому я подумал попробовать так.

>Поэтому я подумал попробовать так.

Подумай ещё.

GCC 4.4 для пользователя отличается только тем, что выявляет больше ошибок в коде. Поэтому нужно править ошибки в коде, а не пытаться на#$ать судьбу играясь версиями компилятора

в пределах 1 ветки не приходится

поставь 4.1.3 из пакетов для CentOS

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

но лучше конечно пропатчить и патч в апстрим авторам отправить

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

Грабли с вероятностьб >50% вылезут в процессе использования собранной софтины

из-за разных версий GCC? бывает, не не часто, точнее почти не бывает , из примеров могу только firefox назвать, (не)работающий на библиотеках собраных разными версиями GCC

более вероятны конфликты при компоновке с libstdc++
и с слинкованными с нею другими библиотеками,

проявляется вот так:

undefined reference to `std::ctype<char>::_M_widen_init()
const'
collect2: ld returned 1 exit status

>из-за разных версий GCC?

Нет. Из-за ошибок, на которые указывает 4.4 и игнорирует 4.3

это не ошибки , к тому же 4.3 их не просто так игнорирует, а потому что все было включено, для g2p это был <cstdio> заголовок, что сейчас Dims2000 не пишет (а зря), к тому же если вернуться к g2p, то авторы его тестировали с GCC 4.1 - 4.3, так что навряд ли там вылезут грабли именно из-за версии GCC

Если причина несобираемости ТОЛЬКО в невключенных хэдерах (что не факт), то этот трэд не стоит выеденого яйца - нужно просто добавить эти хэдеры и не морочить ж^Hголову ни себе, ни другим

> GCC 4.4 для пользователя отличается только тем, что выявляет больше ошибок в коде. Поэтому нужно править ошибки в коде, а не пытаться на#$ать судьбу играясь версиями компилятора

Я понимаю, что ты говоришь, но мне надо попробовать, чтоб на практике понять. Это же вопрос удобства. Как удобней запустить 2-мерную игрушку http://ru.wikipedia.org/wiki/Nebulus на современном компьютере? Поставить эмулятор ДОС? Или портировать её под Винды?

А если таких игрушек у тебя сто? Что, все портировать?

У меня вопрос возник — а как оно при сборке найдёт свои инклюды, либы и так далее? Раньше надо было в переменных всё указывать, а теперь что, каждый компиллятор сам знает, где у него своё лежит?

> для g2p это был <cstdio> заголовок, что сейчас Dims2000 не пишет (а зря)

Это тот же самый g2p, только предыдущей версии. Там ошибок у меня вылезло гораздо больше. И я подумал поэкспериментировать с разными версиями компилляторов. Хотя меня эта возможность сразу заинтересовала.

>Как удобней запустить 2-мерную игрушку http://ru.wikipedia.org/wiki/Nebulus на современном компьютере? Поставить эмулятор ДОС? Или портировать её под Винды?

По-моему, вы ошиблись форумом. Портирование «под винды» на других форумах обсуждают

>каждый компиллятор сам знает, где у него своё лежит?
да

> Как удобней запустить 2-мерную игрушку http://ru.wikipedia.org/wiki/Nebulus на современном компьютере?

http://toppler.sourceforge.net/

Нифига со старой версией gcc тоже не выходит:

[root@testbed g2p]# python setup.py install --prefix /opt/g2p running install running build running build_py file sequitur_.py (for module sequitur_) not found creating build creating build/lib.linux-i686-2.6 copying Evaluation.py -> build/lib.linux-i686-2.6 copying Minimization.py -> build/lib.linux-i686-2.6 copying SequenceModel.py -> build/lib.linux-i686-2.6 copying SequiturTool.py -> build/lib.linux-i686-2.6 copying g2p.py -> build/lib.linux-i686-2.6 copying misc.py -> build/lib.linux-i686-2.6 copying sequitur.py -> build/lib.linux-i686-2.6 copying symbols.py -> build/lib.linux-i686-2.6 copying tool.py -> build/lib.linux-i686-2.6 file sequitur_.py (for module sequitur_) not found running build_ext building '_sequitur_' extension swigging sequitur.i to sequitur_wrap.cpp swig -python -c++ -shadow -o sequitur_wrap.cpp sequitur.i creating build/temp.linux-i686-2.6 gcc-4.3.5 -fno-strict-aliasing -DNDEBUG -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i686 -mtune=atom -fasynchronous-unwind-tables -D_GNU_SOURCE -fPIC -fwrapv -fPIC -DMULTIGRAM_SIZE=2 -I/usr/lib/python2.6/site-packages/numpy/core/include -I/usr/include/python2.6 -c sequitur_wrap.cpp -o build/temp.linux-i686-2.6/sequitur_wrap.o -fpermissive sequitur_wrap.cpp:1: error: bad value (atom) for -mtune= switch error: command 'gcc-4.3.5' failed with exit status 1

Непонятно два вопроса:

(1) правда, что, gcc-4.3.5 не понимает процессора atom? (2) откуда оно вообще взяло, что нужно оптимизировать для атома?

поддержка атом есть только в 4.5.x
или дистрибутивных (RedHat например) бэкпортах 4.4.x

берет наверное из переменных среды,

set |grep FLAGS

переменные
CFLAGS
CXXFLAGS


можно перед сборкой задавать свои

export CFLAGS="-O2 -march=core2"
export CXXFLAGS=${CFLAGS}

например

Но у меня не атом (насколько я понимаю):


[root@testbed source]# cat /proc/cpuinfo | grep model
model : 23
model name : Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz
model : 23
model name : Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz

разумеется нет

-march=core2

Помогло вот так

export CFLAGS="-O2 -march=core2 -mtune=core2"

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

Фууф....

CXXFLAGS тоже нужно задать, для c++ соответственно

-mtune= не имеет смысл задавать (на то же значение) если был задан -march=

к ошибкам хотя это наверное уже отношения не имеет
если уж патчите - делайте тогда с новым GCC и патч авторам...

Да, CXXFLAG я тоже перезадал в то же значение и только тогда заработало.

грубые ошибки начинаются вот так?
_sequitur_.cc:2810:34: error: numarray/arrayobject.h: No such file or directory


g2p r96

судя по всему оно не находит заголовки numpy

вам правда очень нужно собрать эту старую версию ?

Не знаю почему так, там именно в mtune atom ставится, а в march ставится i686...

> вам правда очень нужно собрать эту старую версию ?

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

поправлю, это не numpy
это python-numarray, предшественник numpy,
http://www.stsci.edu/resources/software_hardware/numarray/

использовать его не рекомендуется

а что не так в новой?
уже же столько способов собрать ) и старым gcc
и

#include <cstdio>

в Utility.hh добавить и собирать GCC 4.4


python setup.py install --prefix=/usr

для инсталляции в системный каталог питона (хотя разводите помойку системе этим)

> а что не так в новой?

Она не заработала со скриптом: http://www.linux.org.ru/forum/development/5238253

Но теперь я думаю, что проще её заставить работать.