Édition des liens

Le
JKB
Bonjour à tous,

J'observe un problème d'édition des liens avec GNU ld. Je suppose
qu'il existe une option quelque part pour régler le problème, mais
je n'ai pas encore trouvé.

Mon souci :

J'ai un exécutable qui, en dehors des bibliothèques du système, est
compilé statiquement. En particulier, il est compilé statiquement
avec une version bien précise d'OpenSSL. Et je désire qu'il reste
compilé statiquement avec une version précise de cette bibliothèque
car l'ABI d'OpenSSL change de 1.0.x à 1.0.y et l'API change de 1.x à
1.y avec des effets de bord rigolos.

Or le même exécutable charge des modules qui utilisent entre autre
libpq.so. Cette bibliothèque est liée à la version d'OpenSSL du
système, soit dans mon cas :
libssl.so.1.0.2 => /usr/lib/x86_64-linux-gnu/libssl.so.1.0.2

Mais il m'arrive de trouver des versions plus exotiques.

Ces modules se chargent, mais lors de l'appel à la base de données,
ça termine par un segfault dès que les deux versions d'OpenSSL
diffèrent. En recompilant un libpq avec ma propre
version d'OpenSSL (ou sans chiffrement), cela fonctionne.

Là, j'avoue ne pas comprendre. libpq pointe vers un fichier
contenant la bonne version d'OpenSSL. Pourquoi essaie-t-il d'utilier
la version d'OpenSSL déjà incluse statiquement dans mon exécutable ?
Et y a-t-il moyen de contourner le problème ? Je pense à une option
de ld qui pourrait faire que les symboles d'OpenSSL ne soient pas
exportés (mais que ceux-là, pour tous les symboles, je sais faire).

Je charge mes modules grâce à dlopen(lib, RTLD_NOW | RTLD_LOCAL).

Naturellement, je cherche une solution portable.

Bien cordialement,

JKB

--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse
=> http://grincheux.de-charybde-en-scylla.fr
=> http://loubardes.de-charybde-en-scylla.fr
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses Page 1 / 2
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Lucas Levrel
Le #26410939
Le 27 septembre 2016, JKB a écrit :
Là, j'avoue ne pas comprendre. libpq pointe vers un fichier
contenant la bonne version d'OpenSSL. Pourquoi essaie-t-il d'utilier
la version d'OpenSSL déjà incluse statiquement dans mon exécutable ?
Et y a-t-il moyen de contourner le problème ? Je pense à une option
de ld qui pourrait faire que les symboles d'OpenSSL ne soient pas
exportés (mais que ceux-là, pour tous les symboles, je sais faire).

Ceci peut-être ?
-u symbol
--undefined=symbol
Force symbol to be entered in the output file as an undefined
symbol. Doing this may, for example, trigger linking of additional
modules from standard libraries. -u may be repeated with different
option arguments to enter additional undefined symbols. This
option is equivalent to the "EXTERN" linker script command.
--
LL
Ἕν οἶδα ὅτι οὐδὲν οἶδα (Σωκράτης)
C'est mieux avé les accents (F. Patte)
JKB
Le #26410938
Le Tue, 27 Sep 2016 16:53:58 +0200,
Lucas Levrel
Le 27 septembre 2016, JKB a écrit :
Là, j'avoue ne pas comprendre. libpq pointe vers un fichier
contenant la bonne version d'OpenSSL. Pourquoi essaie-t-il d'utilier
la version d'OpenSSL déjà incluse statiquement dans mon exécutable ?
Et y a-t-il moyen de contourner le problème ? Je pense à une option
de ld qui pourrait faire que les symboles d'OpenSSL ne soient pas
exportés (mais que ceux-là, pour tous les symboles, je sais faire).

Ceci peut-être ?
-u symbol
--undefined=symbol
Force symbol to be entered in the output file as an undefined
symbol. Doing this may, for example, trigger linking of additional
modules from standard libraries. -u may be repeated with different
option arguments to enter additional undefined symbols. This
option is equivalent to the "EXTERN" linker script command.


C'est une possibilité. Mais la gueule de la ligne de commande me
fait peur... Une entrée -u par entrée dans libssl.a ou
libcrypto.a...
En tout cas, merci du tuyau, le -u m'avait échappé.
Cordialement,
JKB
--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
=> http://loubardes.de-charybde-en-scylla.fr
Nicolas George
Le #26410993
JKB , dans le message écrit :
En particulier, il est compilé statiquement
avec une version bien précise d'OpenSSL.

Avis au public : exactement ce qu'il ne faut jamais faire.
La prochaine fois qu'un problème de sécurité sera corrigé dans OpenSSL, le
correctif arrivera sur les systèmes au bout de quelques jours par le système
de mises à jour, mais l'exécutable de JKB restera troué ad vitam aeternam.
JKB
Le #26411019
Le Tue, 27 Sep 2016 14:56:24 +0000 (UTC),
JKB
Le Tue, 27 Sep 2016 16:53:58 +0200,
Lucas Levrel
Le 27 septembre 2016, JKB a écrit :
Là, j'avoue ne pas comprendre. libpq pointe vers un fichier
contenant la bonne version d'OpenSSL. Pourquoi essaie-t-il d'utilier
la version d'OpenSSL déjà incluse statiquement dans mon exécutable ?
Et y a-t-il moyen de contourner le problème ? Je pense à une option
de ld qui pourrait faire que les symboles d'OpenSSL ne soient pas
exportés (mais que ceux-là, pour tous les symboles, je sais faire).

Ceci peut-être ?
-u symbol
--undefined=symbol
Force symbol to be entered in the output file as an undefined
symbol. Doing this may, for example, trigger linking of additional
modules from standard libraries. -u may be repeated with different
option arguments to enter additional undefined symbols. This
option is equivalent to the "EXTERN" linker script command.


C'est une possibilité. Mais la gueule de la ligne de commande me
fait peur... Une entrée -u par entrée dans libssl.a ou
libcrypto.a...
En tout cas, merci du tuyau, le -u m'avait échappé.

Le -u n'este pas probant. En revanche, en continuant mes lectures,
je suis tombé sur --exclude-libs qui semble faire ce qu'il faut.
Sauf que je n'arrive pas au résultat escompté :
g++ -Wall -Wextra -g -O2 -mtune=native -march=native -O3
-malign-double -mieee-fp -Wall -funsigned-char -g -Wl,--export-dynamic
-Wl,--exclude-libs,../tools/openssl-1.1.0b/libcrypto.a,../tools/openssl-1.1.0b/libssl.a
...
et j'ai toujours dans l'exécutable obtenu les symboles d'OpenSSL
exportés comme si de rien n'était...
Cordialement,
JKB
--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
=> http://loubardes.de-charybde-en-scylla.fr
JKB
Le #26411022
Le Wed, 28 Sep 2016 11:43:06 +0000 (UTC),
JKB
Le Tue, 27 Sep 2016 14:56:24 +0000 (UTC),
JKB
Le Tue, 27 Sep 2016 16:53:58 +0200,
Lucas Levrel
Le 27 septembre 2016, JKB a écrit :
Là, j'avoue ne pas comprendre. libpq pointe vers un fichier
contenant la bonne version d'OpenSSL. Pourquoi essaie-t-il d'utilier
la version d'OpenSSL déjà incluse statiquement dans mon exécutable ?
Et y a-t-il moyen de contourner le problème ? Je pense à une option
de ld qui pourrait faire que les symboles d'OpenSSL ne soient pas
exportés (mais que ceux-là, pour tous les symboles, je sais faire).

Ceci peut-être ?
-u symbol
--undefined=symbol
Force symbol to be entered in the output file as an undefined
symbol. Doing this may, for example, trigger linking of additional
modules from standard libraries. -u may be repeated with different
option arguments to enter additional undefined symbols. This
option is equivalent to the "EXTERN" linker script command.


C'est une possibilité. Mais la gueule de la ligne de commande me
fait peur... Une entrée -u par entrée dans libssl.a ou
libcrypto.a...
En tout cas, merci du tuyau, le -u m'avait échappé.

Le -u n'este pas probant. En revanche, en continuant mes lectures,
je suis tombé sur --exclude-libs qui semble faire ce qu'il faut.
Sauf que je n'arrive pas au résultat escompté :
g++ -Wall -Wextra -g -O2 -mtune=native -march=native -O3
-malign-double -mieee-fp -Wall -funsigned-char -g -Wl,--export-dynamic
-Wl,--exclude-libs,../tools/openssl-1.1.0b/libcrypto.a,../tools/openssl-1.1.0b/libssl.a
...
et j'ai toujours dans l'exécutable obtenu les symboles d'OpenSSL
exportés comme si de rien n'était...

Précision : avec -Wl,--exclude-libs,ALL, tous les symboles des
archives sont bien retirés. Je suppose que j'ai raté quelque
chose...
Une idée ?
JKB
--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
=> http://loubardes.de-charybde-en-scylla.fr
Lucas Levrel
Le #26411068
Le 28 septembre 2016, Nicolas George a écrit :
JKB , dans le message écrit :
En particulier, il est compilé statiquement
avec une version bien précise d'OpenSSL.

Avis au public : exactement ce qu'il ne faut jamais faire.
La prochaine fois qu'un problème de sécurité sera corrigé dans OpenSSL, le
correctif arrivera sur les systèmes au bout de quelques jours par le système
de mises à jour, mais l'exécutable de JKB restera troué ad vitam aeternam.

Et inversement : la prochaine fois qu'un trou sera ajouté (genre
heartbleed), il arrivera... etc. :-)
--
LL
Ἕν οἶδα ὅτι οὐδὲν οἶδα (Σωκράτης)
C'est mieux avé les accents (F. Patte)
Lucas Levrel
Le #26411067
Le 28 septembre 2016, JKB a écrit :
Le -u n'este pas probant. En revanche, en continuant mes lectures,
je suis tombé sur --exclude-libs qui semble faire ce qu'il faut.
Sauf que je n'arrive pas au résultat escompté :
g++ -Wall -Wextra -g -O2 -mtune=native -march=native -O3
-malign-double -mieee-fp -Wall -funsigned-char -g -Wl,--export-dynamic
-Wl,--exclude-libs,../tools/openssl-1.1.0b/libcrypto.a,../tools/openssl-1.1.0b/libssl.a
...
et j'ai toujours dans l'exécutable obtenu les symboles d'OpenSSL
exportés comme si de rien n'était...

Précision : avec -Wl,--exclude-libs,ALL, tous les symboles des
archives sont bien retirés. Je suppose que j'ai raté quelque
chose...
Une idée ?

Deux :
- sûr de la façon de spécifier les bibli à exclure (chemin absolu ? pas de
chemin ?) ;
- la doc de --export-dynamic pointe sur --dynamic-list : une autre façon
de faire ? (Lister ce que tu veux exporter plutôt que cacher ce que tu ne
veux pas.)
--
LL
Ἕν οἶδα ὅτι οὐδὲν οἶδα (Σωκράτης)
C'est mieux avé les accents (F. Patte)
JKB
Le #26411153
Le Wed, 28 Sep 2016 19:12:36 +0200,
Lucas Levrel
Le 28 septembre 2016, Nicolas George a écrit :
JKB , dans le message écrit :
En particulier, il est compilé statiquement
avec une version bien précise d'OpenSSL.

Avis au public : exactement ce qu'il ne faut jamais faire.
La prochaine fois qu'un problème de sécurité sera corrigé dans OpenSSL, le
correctif arrivera sur les systèmes au bout de quelques jours par le système
de mises à jour, mais l'exécutable de JKB restera troué ad vitam aeternam.

Et inversement : la prochaine fois qu'un trou sera ajouté (genre
heartbleed), il arrivera... etc. :-)

Nicolas, je t'ai plonké parce que tes avis à l'emporte-pièce sont
ceux d'une merde qui croit tout savoir parce qu'elle a fait Ulm et
qui ne sait rien. Et je pèse mes mots. Tu n'arrives pas à imaginer
que le problème peut être exactement le contraire de ce que ton
esprit obtus et étroit peut imaginer. En l'occurrence, mon problème
est plutôt de faire tourner un soft sur des OS qui proposent par
défaut OpenSSL 9.8.x et 1.0.0.
Maintenant, j'ai posé une question précise. Si tu as une réponse à
apporter à la question, tu peux répondre. Dans le cas présent, tu me
fais surtout penser à Montant qui donnait son avis sur la Pologne
lorsqu'on lui demandait de chanter les feuilles mortes.
<EOT>
--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
=> http://loubardes.de-charybde-en-scylla.fr
JKB
Le #26411155
Le Wed, 28 Sep 2016 19:15:20 +0200,
Lucas Levrel
Le 28 septembre 2016, JKB a écrit :
Le -u n'este pas probant. En revanche, en continuant mes lectures,
je suis tombé sur --exclude-libs qui semble faire ce qu'il faut.
Sauf que je n'arrive pas au résultat escompté :
g++ -Wall -Wextra -g -O2 -mtune=native -march=native -O3
-malign-double -mieee-fp -Wall -funsigned-char -g -Wl,--export-dynamic
-Wl,--exclude-libs,../tools/openssl-1.1.0b/libcrypto.a,../tools/openssl-1.1.0b/libssl.a
...
et j'ai toujours dans l'exécutable obtenu les symboles d'OpenSSL
exportés comme si de rien n'était...

Précision : avec -Wl,--exclude-libs,ALL, tous les symboles des
archives sont bien retirés. Je suppose que j'ai raté quelque
chose...
Une idée ?

Deux :
- sûr de la façon de spécifier les bibli à exclure (chemin absolu ? pas de
chemin ?) ;

Non, non, ça, c'est bon. Si je ne mets pas le chemin absolu, ld râle
copieusement. J'ai aussi essayé d'utiliser -L<chemin> -l<lib> au
lieu d'inclure brutalement l'archive, ça ne chance rien au problème.
- la doc de --export-dynamic pointe sur --dynamic-list : une autre façon
de faire ? (Lister ce que tu veux exporter plutôt que cacher ce que tu ne
veux pas.)

Oui, j'ai vu, mais ça risque d'être un peu tordu à mettre en oeuvre.
Je pense que je vais aller poser brutalement la question chez les
devs de ld.
Bien cordialement,
JKB
--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
=> http://loubardes.de-charybde-en-scylla.fr
Nicolas George
Le #26411154
JKB , dans le message écrit :
Nicolas, je t'ai plonké parce que tes avis à l'emporte-pièce sont
ceux d'une merde qui croit tout savoir parce qu'elle a fait Ulm et
qui ne sait rien. Et je pèse mes mots. Tu n'arrives pas à imaginer
que le problème peut être exactement le contraire de ce que ton
esprit obtus et étroit peut imaginer. En l'occurrence, mon problème
est plutôt de faire tourner un soft sur des OS qui proposent par
défaut OpenSSL 9.8.x et 1.0.0.

L'attaque ad-hominem tout de suite. De toute évidence, aucun argument sur le
fond : la pratique que tu t'efforces de mettre en place est bien une
catastrophe vis-à-vis des mises à jour de sécurité.
Publicité
Poster une réponse
Anonyme