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
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)
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)
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 Tue, 27 Sep 2016 16:53:58 +0200, Lucas Levrel écrivait :
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
Le Tue, 27 Sep 2016 16:53:58 +0200,
Lucas Levrel <lucas.levrel@u-pec.fr> écrivait :
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
Le Tue, 27 Sep 2016 16:53:58 +0200, Lucas Levrel écrivait :
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
JKB , dans le message , a é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 , dans le message <slrnnukcfj.4ku.jkb@rayleigh.systella.fr>, a
é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.
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.
Le Tue, 27 Sep 2016 16:53:58 +0200, Lucas Levrel écrivait :
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
Le Tue, 27 Sep 2016 16:53:58 +0200,
Lucas Levrel <lucas.levrel@u-pec.fr> écrivait :
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é :
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
Le Tue, 27 Sep 2016 16:53:58 +0200, Lucas Levrel écrivait :
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
Le Tue, 27 Sep 2016 16:53:58 +0200, Lucas Levrel écrivait :
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
Le Tue, 27 Sep 2016 16:53:58 +0200,
Lucas Levrel <lucas.levrel@u-pec.fr> écrivait :
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é :
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
Le Tue, 27 Sep 2016 16:53:58 +0200, Lucas Levrel écrivait :
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 28 septembre 2016, Nicolas George a écrit :
JKB , dans le message , a é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)
Le 28 septembre 2016, Nicolas George a écrit :
JKB , dans le message <slrnnukcfj.4ku.jkb@rayleigh.systella.fr>, a
é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)
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 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)
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.)
--
LL
Ἕν οἶδα ὅτι οὐδὲν οἶδα (Σωκράτης)
C'est mieux avé les accents (F. Patte)
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 Wed, 28 Sep 2016 19:12:36 +0200, Lucas Levrel écrivait :
Le 28 septembre 2016, Nicolas George a écrit :
JKB , dans le message , a é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
Le Wed, 28 Sep 2016 19:12:36 +0200,
Lucas Levrel <lucas.levrel@u-pec.fr> écrivait :
Le 28 septembre 2016, Nicolas George a écrit :
JKB , dans le message <slrnnukcfj.4ku.jkb@rayleigh.systella.fr>, a
é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
Le Wed, 28 Sep 2016 19:12:36 +0200, Lucas Levrel écrivait :
Le 28 septembre 2016, Nicolas George a écrit :
JKB , dans le message , a é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 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 ?) ;
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
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 ?) ;
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
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 ?) ;
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
JKB , dans le message , a é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é.
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
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é.
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é.
