Comment puis-je définir rpath sur les binarys gcc pendant le bootstrap?

J’ai trouvé que la copie des répertoires sources pour gmp, mpfr, mpc, isl, cloog, etc. dans le répertoire source gcc de premier niveau (ou l’utilisation de liens symboliques portant le même nom) fonctionne partout. C’est en fait la voie privilégiée.

Vous devez copier (ou lier) ces noms de répertoire source sans les numéros de version pour que cela fonctionne.

Les compilateurs n’ont pas besoin de LD_LIBRARY_PATH (bien que les applications exécutées avec les compilateurs auront besoin d’un LD_LIBRARY_PATH pour $ PREFIX / lib64 ou quelque chose du genre – mais c’est différent)

Commencez dans un répertoire source où vous conserverez toutes vos sources. Dans ce répertoire source, vous avez votre répertoire gcc en décompressant une archive ou svn … J’utilise subversion.

Aussi dans ce répertoire de haut niveau, vous avez, par exemple, les archives source suivantes:

 gmp-5.1.0.tar.bz2 mpfr-3.1.1.tar.bz2 mpc-1.0.1.tar.gz isl-0.11.1.tar.bz2 cloog-0.18.0.tar.gz 

Je viens de télécharger ceux-ci et mettre à jour les dernières archives tar périodiquement.

Sous forme de script:

 # Either: svn checkout svn://gcc.gnu.org/svn/gcc/trunk gcc_work # Or: bunzip -c gcc-4.8.0.tar.bz2 | tar -xvf - mv gcc-4.8.0 gcc_work # Uncompress sources.. (This will produce version numbered directories). bunzip -c gmp-5.1.0.tar.bz2 | tar -xvf - bunzip -c mpfr-3.1.1.tar.bz2 | tar -xvf - gunzip -c mpc-1.0.1.tar.gz | tar -xvf - bunzip -c isl-0.11.1.tar.bz2 | tar -xvf - gunzip -c cloog-0.18.0.tar.gz | tar -xvf - # Link outside source directories into the top level gcc directory. cd gcc_work ln -s ../gmp-5.1.0 gmp ln -s ../mpfr-3.1.1 mpfr ln -s ../mpc-1.0.1 mpc ln -s ../isl-0.11.1 isl ln -s ../cloog-0.18.0 cloog # Get out of the gcc working directory and create a build directory. I call mine obj_work. # I configure the gcc binary and other outputs to be bin_work in the top level directory. Your choice. But I have this: # home/ed/projects # home/ed/projects/gcc_work # home/ed/projects/obj_work # home/ed/projects/bin_work # home/ed/projects/gmp-5.1.0 # home/ed/projects/mpfr-3.1.1 # home/ed/projects/mpc-1.0.1 # home/ed/projects/isl-0.11.1 # home/ed/projects/cloog-0.18.0 mkdir obj_work cd obj_work ../gcc_work/configure --prefix=../bin_work  # Your  shouldn't need to involve anything about gmp, mpfr, mpc, isl, cloog. # The gcc build system will find the directories you linked, # then configure and comstack the needed libraries with the necessary flags and such. # Good luck. 

J’ai utilisé cette option de configure avec gcc-4.8.0, sur FreeBSD, après avoir créé et installé gmp, isl et cloog:

 LD_LIBRARY_PATH=/path/to/isl/lib ./configure (lots of other options) \ --with-stage1-ldflags="-rpath /path/to/isl/lib -rpath /path/to/cloog/lib -rpath /path/to/gmp/lib" 

et le binary gcc résultant n’a pas besoin de LD_LIBRARY_PATH . LD_LIBRARY_PATH pour configure est nécessaire car il comstack un programme de test pour vérifier la version ISL, qui échouerait s’il ne trouvait pas la lib du partage ISL.

Je l’ai essayé sous Linux (Ubuntu) où il a échoué lors de la configuration car les -rpath ont été transmis à gcc au lieu de ld. Je pourrais résoudre ce problème en utilisant

 --with-stage1-ldflags="-Wl,-rpath,/path/to/isl/lib,-rpath,/path/to/cloog/lib,-rpath,/path/to/gmp/lib" 

au lieu.

L’utilisation de configure --with-stage1-ldflags="-Wl,-rpath,/path/to/lib" ne me suffisait pas pour construire gcc 4.9.2, le bootstrap a échoué à l’étape 2. Ce qui fonctionne est de passer les drapeaux directement pour faire via

 make BOOT_LDFLAGS="-Wl,-rpath,/path/to/lib" 

Je l’ai eu de https://gcc.gnu.org/ml/gcc/2008-09/msg00214.html

Bien qu’il s’agisse toujours de définir des variables d’environnement, ce que je fais, c’est définir LD_RUN_PATH, qui définit le chemin d’access. De cette manière, le rest du système peut continuer à utiliser les bibliothèques fournies par le système au lieu d’utiliser celles générées par votre version gcc.

Je vais faire une suggestion qui, à mon avis, résout votre problème, même si cela ne répond absolument pas à votre question. Voyons combien de downvotes je reçois.

Écrire un script d’encapsulation générique pour définir LD_LIBRARY_PATH puis exécuter l’exécutable est facile. voir https://stackoverflow.com/a/7101577/768469 .

L’idée est de passer quelque chose comme --prefix=$PREFIX/install pour configure , en construisant un arbre d’installation qui ressemble à ceci:

 $PREFIX/ install/ lib/ libcloogXX.so libgmpYY.so ... bin/ gcc emacs ... bin/ .wrapper gcc -> .wrapper emacs -> .wrapper 

.wrapper est un script shell simple:

 #!/bin/sh here="${0%/*}" # or use $(dirname "$0") base="${0##*/}" # or use $(basename "$0") libdir="$here"/../install/lib if [ "$LD_LIBRARY_PATH"x = x ] ; then LD_LIBRARY_PATH="$libdir" else LD_LIBRARY_PATH="$libdir":"$LD_LIBRARY_PATH" fi export LD_LIBRARY_PATH exec "$here"/../install/bin/"$base" "$@" 

Cela va transférer tous les arguments correctement, gérer les espaces dans les arguments ou les noms de répertoire, etc. Pour des raisons pratiques, il est impossible de distinguer le rpath comme vous le souhaitez.

En outre, vous pouvez utiliser cette approche non seulement pour gcc, mais pour toute votre arborescence my-personal- $PREFIX . Je le fais tout le temps dans des environnements où je veux une suite à jour d’outils GNU, mais je n’ai pas (ou je ne veux pas admettre) un access root.

Essayez d’append votre $PREFIX à /etc/ld.so.conf , puis lancez ldconfig:

 # echo $PREFIX >> /etc/ld.so.conf # ldconfig 

Cela recréera le cache utilisé par l’éditeur de liens d’exécution et récupérera vos bibliothèques.

AVERTISSEMENT: cette opération entraînera TOUTES les applications à utiliser vos bibliothèques nouvellement compilées dans $PREFIX au lieu de l’emplacement par défaut