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
Le Wed, 28 Sep 2016 19:15:20 +0200, Lucas Levrel écrivait :
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.)
Solution : n'indiquer que le nom de la bibliothèque, sans le chemin. Reste à savoir pourquoi cela fonctionne en ligne de commande et pas depuis mon Makefile généré par automake/autoconf. Mais c'est un autre problème, j'ai dû écrire une conceté quelque part. 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
Le Wed, 28 Sep 2016 19:15:20 +0200,
Lucas Levrel <lucas.levrel@u-pec.fr> écrivait :
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é :
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.)
Solution : n'indiquer que le nom de la bibliothèque, sans le chemin.
Reste à savoir pourquoi cela fonctionne en ligne de commande et pas
depuis mon Makefile généré par automake/autoconf. Mais c'est un
autre problème, j'ai dû écrire une conceté quelque part.
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
Le Wed, 28 Sep 2016 19:15:20 +0200, Lucas Levrel écrivait :
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.)
Solution : n'indiquer que le nom de la bibliothèque, sans le chemin. Reste à savoir pourquoi cela fonctionne en ligne de commande et pas depuis mon Makefile généré par automake/autoconf. Mais c'est un autre problème, j'ai dû écrire une conceté quelque part. 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
Dominique MICOLLET
Bonjour, Nicolas George wrote:
JKB , dans le message , a écrit :
Nicolas, je t'ai plonké parce que tes avis à l'emporte-pièce sont
...
catastrophe vis-à-vis des mises à jour de sécurité.
Vous avez raison tout les deux : - il faut faire tout ce qu'on peut pour qu'un système soit sécurisé ; - il y a des clients qui ne veulent pas qu'un système soit sécurisé. On a tous bien compris que la démarche de JKB est dangereuse, et Nicolas prévient les novices de ce danger. Après chacun est "libre" de faire ce qu'il veut, ou plutôt ce qu'il peut quand il a des contraintes extérieures. Cordialement Dominique
Bonjour,
Nicolas George wrote:
JKB , dans le message <slrnnupetm.bci.jkb@rayleigh.systella.fr>, a
écrit :
Nicolas, je t'ai plonké parce que tes avis à l'emporte-pièce sont
...
catastrophe vis-à-vis des mises à jour de sécurité.
Vous avez raison tout les deux :
- il faut faire tout ce qu'on peut pour qu'un système soit sécurisé ;
- il y a des clients qui ne veulent pas qu'un système soit sécurisé.
On a tous bien compris que la démarche de JKB est dangereuse, et Nicolas
prévient les novices de ce danger.
Après chacun est "libre" de faire ce qu'il veut, ou plutôt ce qu'il peut
quand il a des contraintes extérieures.
Nicolas, je t'ai plonké parce que tes avis à l'emporte-pièce sont
...
catastrophe vis-à-vis des mises à jour de sécurité.
Vous avez raison tout les deux : - il faut faire tout ce qu'on peut pour qu'un système soit sécurisé ; - il y a des clients qui ne veulent pas qu'un système soit sécurisé. On a tous bien compris que la démarche de JKB est dangereuse, et Nicolas prévient les novices de ce danger. Après chacun est "libre" de faire ce qu'il veut, ou plutôt ce qu'il peut quand il a des contraintes extérieures. Cordialement Dominique
Nicolas, je t'ai plonké parce que tes avis à l'emporte-pièce sont
...
catastrophe vis-à-vis des mises à jour de sécurité.
Vous avez raison tout les deux : - il faut faire tout ce qu'on peut pour qu'un système soit sécurisé ; - il y a des clients qui ne veulent pas qu'un système soit sécurisé. On a tous bien compris que la démarche de JKB est dangereuse, et Nicolas prévient les novices de ce danger.
Sauf qu'une fois de plus, il réagit sur un problème qu'il ne comprend pas. Le problème est justement d'avoir la dernière mise à jour indépendament des bibliothèques disponibles sur les OS et des API qui changent. Parce que le problème serait tout autre si l'API d'OpenSSL était stable. Lorsque tu veux aujourd'hui utiliser la dernière version de la chose, tu n'as d'autres choix que de mettre à jour tout le système, ce qui est impraticable dans l'immense majorité des cas, surtout pour des calculateurs embarqués qui ne sont pas ouverts vers l'extérieur. Par ailleurs, il ne sait strictement rien sur ce qui est utilisé d'OpenSSL.
Après chacun est "libre" de faire ce qu'il veut, ou plutôt ce qu'il peut quand il a des contraintes extérieures.
Nous sommes bien d'accord. Certains devraient se coltiner des clients plus souvent. 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 , dans le message <slrnnupetm.bci.jkb@rayleigh.systella.fr>, a
écrit :
Nicolas, je t'ai plonké parce que tes avis à l'emporte-pièce sont
...
catastrophe vis-à-vis des mises à jour de sécurité.
Vous avez raison tout les deux :
- il faut faire tout ce qu'on peut pour qu'un système soit sécurisé ;
- il y a des clients qui ne veulent pas qu'un système soit sécurisé.
On a tous bien compris que la démarche de JKB est dangereuse, et Nicolas
prévient les novices de ce danger.
Sauf qu'une fois de plus, il réagit sur un problème qu'il ne
comprend pas. Le problème est justement d'avoir la dernière mise à
jour indépendament des bibliothèques disponibles sur les OS et des
API qui changent. Parce que le problème serait tout autre si l'API
d'OpenSSL était stable. Lorsque tu veux aujourd'hui utiliser la
dernière version de la chose, tu n'as d'autres choix que de mettre à
jour tout le système, ce qui est impraticable dans l'immense
majorité des cas, surtout pour des calculateurs embarqués qui ne
sont pas ouverts vers l'extérieur.
Par ailleurs, il ne sait strictement rien sur ce qui est utilisé
d'OpenSSL.
Après chacun est "libre" de faire ce qu'il veut, ou plutôt ce qu'il peut
quand il a des contraintes extérieures.
Nous sommes bien d'accord. Certains devraient se coltiner des
clients plus souvent.
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, je t'ai plonké parce que tes avis à l'emporte-pièce sont
...
catastrophe vis-à-vis des mises à jour de sécurité.
Vous avez raison tout les deux : - il faut faire tout ce qu'on peut pour qu'un système soit sécurisé ; - il y a des clients qui ne veulent pas qu'un système soit sécurisé. On a tous bien compris que la démarche de JKB est dangereuse, et Nicolas prévient les novices de ce danger.
Sauf qu'une fois de plus, il réagit sur un problème qu'il ne comprend pas. Le problème est justement d'avoir la dernière mise à jour indépendament des bibliothèques disponibles sur les OS et des API qui changent. Parce que le problème serait tout autre si l'API d'OpenSSL était stable. Lorsque tu veux aujourd'hui utiliser la dernière version de la chose, tu n'as d'autres choix que de mettre à jour tout le système, ce qui est impraticable dans l'immense majorité des cas, surtout pour des calculateurs embarqués qui ne sont pas ouverts vers l'extérieur. Par ailleurs, il ne sait strictement rien sur ce qui est utilisé d'OpenSSL.
Après chacun est "libre" de faire ce qu'il veut, ou plutôt ce qu'il peut quand il a des contraintes extérieures.
Nous sommes bien d'accord. Certains devraient se coltiner des clients plus souvent. 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
