J'ai construit de nouvelles versions de gcc pour rhel6 pour plusieurs versions maintenant (depuis 4.7.x à 5.3.1).
Le processus est assez facile grâce aux versions de Jakub Jelinek fedora gcc de Redhat trouvées sur les koji
Prenez simplement le dernier rpm src pour la version dont vous avez besoin (par exemple 5.3.1 ).
Fondamentalement, vous commenceriez par déterminer les exigences de génération en émettant la rpm -qpR src.rpmrecherche des exigences de version:
rpm -qpR gcc-5.3.1-4.fc23.src.rpm | grep -E '= [[:digit:]]'
binutils >= 2.24
doxygen >= 1.7.1
elfutils-devel >= 0.147
elfutils-libelf-devel >= 0.147
gcc-gnat >= 3.1
glibc-devel >= 2.4.90-13
gmp-devel >= 4.1.2-8
isl = 0.14
isl-devel = 0.14
libgnat >= 3.1
libmpc-devel >= 0.8.1
mpfr-devel >= 2.2.1
rpmlib(CompressedFileNames) <= 3.0.4-1
rpmlib(FileDigests) <= 4.6.0-1
systemtap-sdt-devel >= 1.3
Vient maintenant la partie fastidieuse - tout package qui a une version supérieure à celle fournie par yum fro votre distribution doit être téléchargé à partir de koji , et répéter récursivement le processus jusqu'à ce que toutes les exigences de dépendance soient remplies.
Je triche, btw.
Je reconditionne habituellement le rpm pour contenir un arbre de construction correct en utilisant la fonction gnu pour utiliser des exigences correctement placées et nommées, de sorte que gmp / mpc / mpfr / isl (cloog n'est plus requis) sont téléchargés et déplacés vers le chemin correct, et le nouveau (gonflé) tar est reconstruit dans un nouveau rpm src (avec des modifications mineures au fichier spec) sans aucune dépendance sur leurs versions packagées (rpm). Comme je ne connais personne utilisant ADA, je supprime simplement les parties relatives à gnat du fichier de spécifications, simplifiant davantage le processus de construction, me laissant avec seulement des binutils à craindre.
Gcc peut réellement construire avec des binutils plus anciens, donc si vous êtes pressé, éditez davantage le fichier de spécifications pour exiger la version de binutils déjà présente sur votre système. Cela se traduira par un gcc légèrement paralysé, mais surtout il fonctionnera assez bien.
Cela fonctionne assez bien la plupart du temps.
MISE À JOUR 1
La méthode la plus simple pour ouvrir un rpm src est probablement yum installer le rpm et accéder à tout sous ~ / rpmbuild, mais je préfère
mkdir gcc-5.3.1-4.fc23
cd gcc-5.3.1-4.fc23
rpm2cpio ../gcc-5.3.1-4.fc23.src.rpm | cpio -id
tar xf gcc-5.3.1-20160212.tar.bz2
cd gcc-5.3.1-20160212
contrib/download_prerequisites
cd ..
tar caf gcc-5.3.1-20160212.tar.bz2 gcc-5.3.1-20160212
rm -rf gcc-5.3.1-20160212
# remove gnat
sed -i '/%global build_ada 1/ s/1/0/' gcc.spec
sed -i '/%if !%{build_ada}/,/%endif/ s/^/#/' gcc.spec
# remove gmp/mpfr/mpc dependencies
sed -i '/BuildRequires: gmp-devel >= 4.1.2-8, mpfr-devel >= 2.2.1, libmpc-devel >= 0.8.1/ s/.*//' gcc.spec
# remove isl dependency
sed -i '/BuildRequires: isl = %{isl_version}/,/Requires: isl-devel = %{isl_version}/ s/^/#/' gcc.spec
# Either build binutils as I do, or lower requirements
sed -i '/Requires: binutils/ s/2.24/2.20/' gcc.spec
# Make sure you don't break on gcc-java
sed -i '/gcc-java/ s/^/#/' gcc.spec
Vous avez également le choix de définir un préfixe afin que ce rpm s'installe côte à côte sans casser le rpm de distribution (mais nécessite un changement de nom et quelques modifications des noms de packages internes). J'ajoute généralement un module d'environnement afin de pouvoir charger et décharger ce gcc comme requis (similaire au fonctionnement des collections) dans le cadre du rpm (donc j'ajoute une nouvelle dépendance).
Enfin, créez l'arborescence rpmbuild et placez les fichiers là où ils devraient aller et construisez:
yum install rpmdevtools rpm-build
rpmdev-setuptree
cp * ~/rpmbuild/SOURCES/
mv ~/rpmbuild/{SOURCES,SPECS}/gcc.spec
rpmbuild -ba ~/rpmbuild/SPECS/gcc.spec
MISE À JOUR 2
Normalement, il ne faut pas utiliser un système d'exploitation "serveur" pour le développement - c'est pourquoi vous avez fedora qui est déjà livré avec le dernier gcc. J'ai des exigences particulières, mais vous devriez vraiment envisager d'utiliser le bon outil pour la tâche - rhel / centos pour exécuter des applications de production, fedora pour développer ces applications, etc.