Malgré ma lecture de ton message et des messages que tu
références sur les autres listes de diffusion, je ne suis pas
certain d'avoir compris le problème initial que tu essaies de
résoudre. Il est donc probable que je réponde un peu à côté.
Avec un peu de chances, j'espère que tu trouveras peut-être au
moins quelque information intéressante.
L'option -rpath passée à l'éditeur de lien (le plus souvent via le
compilateur /usr/bin/g++ ou /usr/bin/gcc ...) permet d'écrire dans le
binaire executable ELF l'information qui serait transmise par un
LD_LIBRARY_PATH (que je ne veux pas utiliser, mais ldconfig sous root).
L'option -rpath me semble surtout utile pour la distribution de
logiciels « clé en main » dans une archive tar, dans laquelle
sont également embarqué des bibliothèques associées au
programme, mais qui n'ont pas à faire partie intégrante du
système d'exploitation. Typiquement, l'édition de lien se fera
relativement au répertoire de ton binaire avec une substitution
$ORIGIN :
gcc -Wl,-rpath,'$ORIGIN/../lib'
De cette manière, un binaire dans /opt/refpersys/bin ira
chercher ses bibliothèques dans /opt/refpersys/lib. Le manuel
de ld.so(8) contient un paragraphe à ce sujet [1], dont la
commande que je me suis permis de copier et coller. J'en
recommande la lecture, il s'y trouve pas mal d'autres astuces
méconnues et parfois utiles.
[1] : https://manpages.debian.org/trixie/manpages-fr/ld.so.8.fr.html#Mots-cl%C3%A9s_de_cha%C3%AEne_dynamiques
Sur un Debian/Trixie ou Sid AMD64 je veux obtenir aussi bien
/lib/x86_64-linux-gnu que /usr/lib/x86_64-linux-gnu et donc la chaîne
de caractères (dans un GNU makefile un peu compliqué)
/lib/x86_64-linux-gnu:/usr/lib/x86_64-linux-gnu/
quelle est donc la commande qui me permet de construire cette chaîne
(dans un GNUmakefile)?
Je suggérerais de ne pas chercher à spécifier les répertoires
système dans le -rpath. Normalement, ils sont configurés dans
/etc/ld.so.conf (et /etc/ld.so.conf.d/*), configuration
appliquée via ldconfig. Soit ils sont correctement configurés,
soit il y a de fortes chances pour que le système en question ne
soit pas en état de marche. Pour Debian sur x86_64,
/usr/lib/x86_64-linux-gnu/ fait déjà partie de la configuration
de l'éditeur de liens :
$ grep 'lib/x86_64-linux-gnu$' /etc/ld.so.conf.d/*
/etc/ld.so.conf.d/x86_64-linux-gnu.conf:/usr/local/lib/x86_64-linux-gnu
/etc/ld.so.conf.d/x86_64-linux-gnu.conf:/usr/lib/x86_64-linux-gnu
Ce sera la même chose sur Raspberry Pi, avec un chemin du type
/usr/lib/aarch64-linux-gnu pour les modèles en 64-bit.
D'autre part, comme l'a souligné didier gaumet, /lib est un lien
symbolique vers /usr/lib, donc leurs contenus sont les mêmes,
rigoureusement :
$ readlink -f /lib/x86_64-linux-gnu
/usr/lib/x86_64-linux-gnu
Si ce n'est pas le cas, c'est-à-dire sur une machine
n'implémentant pas usrmerge, alors /lib/x86_64-linux-gnu devra
en toute logique faire partie de la configuration de l'éditeur
de liens.
En lien avec cette question
https://lists.gnu.org/archive/html/help-make/2026-06/msg00008.html
https://lists.gnu.org/archive/html/lightning/2026-06/msg00006.html
Je ne suis pas convaincu que le problème décrit dans le fil de
discussion sur la liste lightning (à savoir : un problème de
couplage fort avec les libopcodes et libbfd de binutils) puisse
être résolu en ajustant le DT_RUNPATH. Je crois que la solution
que tu as trouvé, c'est-à-dire ajuster l'ordre d'édition des
liens, devrait être suffisante :
A working solution is to link explicitly -lopcodes and -lbfd
after -llightning.
Bonne soirée, :)
--
.''`. Étienne Mollier <emollier@debian.org>
: :' : pgp: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da
`. `' sent from /dev/pts/3, please excuse my verbosity
`-
| Date | Sujet | # | Auteur | |
| 18 Jun 26 |  commande Debian pour obtenir un -rpath suffisamment bon (et portable) | 3 | Basile STARYNKEVITCH | |
| 18 Jun 26 |   Re: commande Debian pour obtenir un -rpath suffisamment bon (et portable) | 1 | didier gaumet | |
| 18 Jun 26 |  Re: commande Debian pour obtenir un -rpath suffisamment bon (et portable) | 1 | Étienne Mollier |
Les messages affichés proviennent d'usenet.