Compiler un exécutable en 64 bits sous Solaris avec gcc/gnu-ld
5 réponses
JKB
Bonjour à tous (et bonne année 2009),
Je disjoncte... Mais vraiment je disjoncte... J'ai un programme de
calcul à compiler sous Solaris 10/Sparc en 64 bits.
Ce programme fonctionne parfaitement et compile sans aucun problème
en 32 bits sur la machine en question (compilateur gcc/gfortran 4.3.2 +
GNU ld correspondant).
J'arrive à compiler en 64 bits avec la chaîne gcc/Solaris ld. Sauf
que cela ne fonctionne pas bien au final car j'ai absolument besoin de
l'option -export-dynamic du linker de GNU. J'ai bien essayé de trouver
l'équivalent dans les nombreuses options du linker de Solaris, mais rien
n'y fait. J'ai besoin que le programme en question exporte ses symboles
vers une bibliothèque dynamique qu'il charge à la volée.
Lorsque j'essaye de compiler en 64 bits avec la chaîne gcc/GNU ld,
je me prends une erreur dès que j'essaye de compiler autre chose que du
C en 64 bits.
int
main()
{
printf("Hello, World!\n");
exit(EXIT_SUCCESS);
}
tchaikovski:[~/test] > gcc -m64 test.c
tchaikovski:[~/test] > file a.out
a.out: ELF 64 bits MSB exécutable SPARCV9 Version 1, avec liens
dynamiques, fichier intégral
tchaikovski:[~/test] > ./a.out
Hello, World!
Parfait. Maintenant, la même chose en Fortran :
tchaikovski:[~/test] > cat test.f90
program TEST
write(*, *) ' Hello, world!'
end
tchaikovski:[~/test] > gfortran -m64 test.f90
tchaikovski:[~/test] > file a.out
a.out: ELF 64 bits MSB exécutable SPARCV9 Version 1, avec liens
dynamiques, fichier intégral
tchaikovski:[~/test] > ./a.out
ld.so.1: a.out: fatal : /usr/shared-apps/lib/libgfortran.so.3 : classe
ELF erronée : ELFCLASS32
Tué
tchaikovski:[~/test] > ldd a.out
libgfortran.so.3 => /usr/shared-apps/lib/libgfortran.so.3
- classe ELF erronée : ELFCLASS32
libm.so.2 => /lib/64/libm.so.2
libgcc_s.so.1 => /usr/shared-apps/lib/libgcc_s.so.1 -
classe ELF erronée : ELFCLASS32
libc.so.1 => /lib/64/libc.so.1
/platform/SUNW,SPARC-Enterprise-T1000/lib/sparcv9/libc_psr.so.1
tchaikovski:[~/test] >
Il va sans dire que les bibliothèques demandées sont présentes sur
le système, mais dans un autre répertoire :
tchaikovski:[/usr/shared-apps/lib/sparcv9] > file libgfortran.so.3
libgfortran.so.3: ELF 64 bits MSB bibliothèque dynamique SPARCV9
Version 1, avec liens dynamiques, fichier intégral
tchaikovski:[/usr/shared-apps/lib/sparcv9] > file ../libgfortran.so.3
../libgfortran.so.3: ELF 32 bits MSB bibliothèque dynamique
SPARC32PLUS Version 1, V8+ requis, avec liens dynamiques, fichier intégral
tchaikovski:[/usr/shared-apps/lib/sparcv9] >
J'ai essayé de truander en imposant ce chemin dans les options du
linker, rien n'y fait et c'est toujours les version 32 bits qui sont
chargées !
Y a-t-il une solution autre que prendre le linker de Solaris qui ne
convient pas ? Pour information :
tchaikovski:[~/test] > gcc -v
Using built-in specs.
Target: sparc-sun-solaris2.10
Configured with: ../configure --prefix=/usr/shared-apps
--enable-languages=c,c++,fortran --enable-shared
--enable-threads=solaris --enable-nls --enable-checking=release
--with-mpfr=/usr/shared-apps/ --with-gnu-ld
Thread model: solaris
gcc version 4.3.2 (GCC)
Merci de vos lumières,
JKB
--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
JKB
Le 11-01-2009, ? propos de Compiler un exécutable en 64 bits sous Solaris avec gcc/gnu-ld, JKB ?crivait dans fr.comp.os.unix :
Bonjour à tous (et bonne année 2009),
Je disjoncte... Mais vraiment je disjoncte... J'ai un programme de calcul à compiler sous Solaris 10/Sparc en 64 bits.
Ce programme fonctionne parfaitement et compile sans aucun problème en 32 bits sur la machine en question (compilateur gcc/gfortran 4.3.2 + GNU ld correspondant).
J'arrive à compiler en 64 bits avec la chaîne gcc/Solaris ld. Sauf que cela ne fonctionne pas bien au final car j'ai absolument besoin de l'option -export-dynamic du linker de GNU. J'ai bien essayé de trouver l'équivalent dans les nombreuses options du linker de Solaris, mais rien n'y fait. J'ai besoin que le programme en question exporte ses symboles vers une bibliothèque dynamique qu'il charge à la volée.
Lorsque j'essaye de compiler en 64 bits avec la chaîne gcc/GNU ld, je me prends une erreur dès que j'essaye de compiler autre chose que du C en 64 bits.
int main() { printf("Hello, World!n"); exit(EXIT_SUCCESS); } tchaikovski:[~/test] > gcc -m64 test.c tchaikovski:[~/test] > file a.out a.out: ELF 64 bits MSB exécutable SPARCV9 Version 1, avec liens dynamiques, fichier intégral tchaikovski:[~/test] > ./a.out Hello, World!
Parfait. Maintenant, la même chose en Fortran :
tchaikovski:[~/test] > cat test.f90 program TEST write(*, *) ' Hello, world!' end tchaikovski:[~/test] > gfortran -m64 test.f90 tchaikovski:[~/test] > file a.out a.out: ELF 64 bits MSB exécutable SPARCV9 Version 1, avec liens dynamiques, fichier intégral tchaikovski:[~/test] > ./a.out ld.so.1: a.out: fatal : /usr/shared-apps/lib/libgfortran.so.3 : classe ELF erronée : ELFCLASS32 Tué tchaikovski:[~/test] > ldd a.out libgfortran.so.3 => /usr/shared-apps/lib/libgfortran.so.3 - classe ELF erronée : ELFCLASS32 libm.so.2 => /lib/64/libm.so.2 libgcc_s.so.1 => /usr/shared-apps/lib/libgcc_s.so.1 - classe ELF erronée : ELFCLASS32 libc.so.1 => /lib/64/libc.so.1 /platform/SUNW,SPARC-Enterprise-T1000/lib/sparcv9/libc_psr.so.1 tchaikovski:[~/test] >
Il va sans dire que les bibliothèques demandées sont présentes sur le système, mais dans un autre répertoire : tchaikovski:[/usr/shared-apps/lib/sparcv9] > file libgfortran.so.3 libgfortran.so.3: ELF 64 bits MSB bibliothèque dynamique SPARCV9 Version 1, avec liens dynamiques, fichier intégral tchaikovski:[/usr/shared-apps/lib/sparcv9] > file ../libgfortran.so.3 ../libgfortran.so.3: ELF 32 bits MSB bibliothèque dynamique SPARC32PLUS Version 1, V8+ requis, avec liens dynamiques, fichier intégral tchaikovski:[/usr/shared-apps/lib/sparcv9] >
J'ai essayé de truander en imposant ce chemin dans les options du linker, rien n'y fait et c'est toujours les version 32 bits qui sont chargées !
Y a-t-il une solution autre que prendre le linker de Solaris qui ne convient pas ? Pour information :
tchaikovski:[~/test] > gcc -v Using built-in specs. Target: sparc-sun-solaris2.10 Configured with: ../configure --prefix=/usr/shared-apps --enable-languages=c,c++,fortran --enable-shared --enable-threads=solaris --enable-nls --enable-checking=release --with-mpfr=/usr/shared-apps/ --with-gnu-ld Thread model: solaris gcc version 4.3.2 (GCC)
Merci de vos lumières,
Groumpfff. Au moment où j'écris, je m'aperçois qu'un LD_LIBRARY_PATH règle en partie le problème. Ce n'est pas propre, mais je vais vois s'il est possible de bricoler quelque chose par là...
Cordialement,
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
Le 11-01-2009, ? propos de
Compiler un exécutable en 64 bits sous Solaris avec gcc/gnu-ld,
JKB ?crivait dans fr.comp.os.unix :
Bonjour à tous (et bonne année 2009),
Je disjoncte... Mais vraiment je disjoncte... J'ai un programme de
calcul à compiler sous Solaris 10/Sparc en 64 bits.
Ce programme fonctionne parfaitement et compile sans aucun problème
en 32 bits sur la machine en question (compilateur gcc/gfortran 4.3.2 +
GNU ld correspondant).
J'arrive à compiler en 64 bits avec la chaîne gcc/Solaris ld. Sauf
que cela ne fonctionne pas bien au final car j'ai absolument besoin de
l'option -export-dynamic du linker de GNU. J'ai bien essayé de trouver
l'équivalent dans les nombreuses options du linker de Solaris, mais rien
n'y fait. J'ai besoin que le programme en question exporte ses symboles
vers une bibliothèque dynamique qu'il charge à la volée.
Lorsque j'essaye de compiler en 64 bits avec la chaîne gcc/GNU ld,
je me prends une erreur dès que j'essaye de compiler autre chose que du
C en 64 bits.
int
main()
{
printf("Hello, World!n");
exit(EXIT_SUCCESS);
}
tchaikovski:[~/test] > gcc -m64 test.c
tchaikovski:[~/test] > file a.out
a.out: ELF 64 bits MSB exécutable SPARCV9 Version 1, avec liens
dynamiques, fichier intégral
tchaikovski:[~/test] > ./a.out
Hello, World!
Parfait. Maintenant, la même chose en Fortran :
tchaikovski:[~/test] > cat test.f90
program TEST
write(*, *) ' Hello, world!'
end
tchaikovski:[~/test] > gfortran -m64 test.f90
tchaikovski:[~/test] > file a.out
a.out: ELF 64 bits MSB exécutable SPARCV9 Version 1, avec liens
dynamiques, fichier intégral
tchaikovski:[~/test] > ./a.out
ld.so.1: a.out: fatal : /usr/shared-apps/lib/libgfortran.so.3 : classe
ELF erronée : ELFCLASS32
Tué
tchaikovski:[~/test] > ldd a.out
libgfortran.so.3 => /usr/shared-apps/lib/libgfortran.so.3
- classe ELF erronée : ELFCLASS32
libm.so.2 => /lib/64/libm.so.2
libgcc_s.so.1 => /usr/shared-apps/lib/libgcc_s.so.1 -
classe ELF erronée : ELFCLASS32
libc.so.1 => /lib/64/libc.so.1
/platform/SUNW,SPARC-Enterprise-T1000/lib/sparcv9/libc_psr.so.1
tchaikovski:[~/test] >
Il va sans dire que les bibliothèques demandées sont présentes sur
le système, mais dans un autre répertoire :
tchaikovski:[/usr/shared-apps/lib/sparcv9] > file libgfortran.so.3
libgfortran.so.3: ELF 64 bits MSB bibliothèque dynamique SPARCV9
Version 1, avec liens dynamiques, fichier intégral
tchaikovski:[/usr/shared-apps/lib/sparcv9] > file ../libgfortran.so.3
../libgfortran.so.3: ELF 32 bits MSB bibliothèque dynamique
SPARC32PLUS Version 1, V8+ requis, avec liens dynamiques, fichier intégral
tchaikovski:[/usr/shared-apps/lib/sparcv9] >
J'ai essayé de truander en imposant ce chemin dans les options du
linker, rien n'y fait et c'est toujours les version 32 bits qui sont
chargées !
Y a-t-il une solution autre que prendre le linker de Solaris qui ne
convient pas ? Pour information :
tchaikovski:[~/test] > gcc -v
Using built-in specs.
Target: sparc-sun-solaris2.10
Configured with: ../configure --prefix=/usr/shared-apps
--enable-languages=c,c++,fortran --enable-shared
--enable-threads=solaris --enable-nls --enable-checking=release
--with-mpfr=/usr/shared-apps/ --with-gnu-ld
Thread model: solaris
gcc version 4.3.2 (GCC)
Merci de vos lumières,
Groumpfff. Au moment où j'écris, je m'aperçois qu'un LD_LIBRARY_PATH
règle en partie le problème. Ce n'est pas propre, mais je vais vois s'il
est possible de bricoler quelque chose par là...
Cordialement,
JKB
--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.
Le 11-01-2009, ? propos de Compiler un exécutable en 64 bits sous Solaris avec gcc/gnu-ld, JKB ?crivait dans fr.comp.os.unix :
Bonjour à tous (et bonne année 2009),
Je disjoncte... Mais vraiment je disjoncte... J'ai un programme de calcul à compiler sous Solaris 10/Sparc en 64 bits.
Ce programme fonctionne parfaitement et compile sans aucun problème en 32 bits sur la machine en question (compilateur gcc/gfortran 4.3.2 + GNU ld correspondant).
J'arrive à compiler en 64 bits avec la chaîne gcc/Solaris ld. Sauf que cela ne fonctionne pas bien au final car j'ai absolument besoin de l'option -export-dynamic du linker de GNU. J'ai bien essayé de trouver l'équivalent dans les nombreuses options du linker de Solaris, mais rien n'y fait. J'ai besoin que le programme en question exporte ses symboles vers une bibliothèque dynamique qu'il charge à la volée.
Lorsque j'essaye de compiler en 64 bits avec la chaîne gcc/GNU ld, je me prends une erreur dès que j'essaye de compiler autre chose que du C en 64 bits.
int main() { printf("Hello, World!n"); exit(EXIT_SUCCESS); } tchaikovski:[~/test] > gcc -m64 test.c tchaikovski:[~/test] > file a.out a.out: ELF 64 bits MSB exécutable SPARCV9 Version 1, avec liens dynamiques, fichier intégral tchaikovski:[~/test] > ./a.out Hello, World!
Parfait. Maintenant, la même chose en Fortran :
tchaikovski:[~/test] > cat test.f90 program TEST write(*, *) ' Hello, world!' end tchaikovski:[~/test] > gfortran -m64 test.f90 tchaikovski:[~/test] > file a.out a.out: ELF 64 bits MSB exécutable SPARCV9 Version 1, avec liens dynamiques, fichier intégral tchaikovski:[~/test] > ./a.out ld.so.1: a.out: fatal : /usr/shared-apps/lib/libgfortran.so.3 : classe ELF erronée : ELFCLASS32 Tué tchaikovski:[~/test] > ldd a.out libgfortran.so.3 => /usr/shared-apps/lib/libgfortran.so.3 - classe ELF erronée : ELFCLASS32 libm.so.2 => /lib/64/libm.so.2 libgcc_s.so.1 => /usr/shared-apps/lib/libgcc_s.so.1 - classe ELF erronée : ELFCLASS32 libc.so.1 => /lib/64/libc.so.1 /platform/SUNW,SPARC-Enterprise-T1000/lib/sparcv9/libc_psr.so.1 tchaikovski:[~/test] >
Il va sans dire que les bibliothèques demandées sont présentes sur le système, mais dans un autre répertoire : tchaikovski:[/usr/shared-apps/lib/sparcv9] > file libgfortran.so.3 libgfortran.so.3: ELF 64 bits MSB bibliothèque dynamique SPARCV9 Version 1, avec liens dynamiques, fichier intégral tchaikovski:[/usr/shared-apps/lib/sparcv9] > file ../libgfortran.so.3 ../libgfortran.so.3: ELF 32 bits MSB bibliothèque dynamique SPARC32PLUS Version 1, V8+ requis, avec liens dynamiques, fichier intégral tchaikovski:[/usr/shared-apps/lib/sparcv9] >
J'ai essayé de truander en imposant ce chemin dans les options du linker, rien n'y fait et c'est toujours les version 32 bits qui sont chargées !
Y a-t-il une solution autre que prendre le linker de Solaris qui ne convient pas ? Pour information :
tchaikovski:[~/test] > gcc -v Using built-in specs. Target: sparc-sun-solaris2.10 Configured with: ../configure --prefix=/usr/shared-apps --enable-languages=c,c++,fortran --enable-shared --enable-threads=solaris --enable-nls --enable-checking=release --with-mpfr=/usr/shared-apps/ --with-gnu-ld Thread model: solaris gcc version 4.3.2 (GCC)
Merci de vos lumières,
Groumpfff. Au moment où j'écris, je m'aperçois qu'un LD_LIBRARY_PATH règle en partie le problème. Ce n'est pas propre, mais je vais vois s'il est possible de bricoler quelque chose par là...
Cordialement,
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
Marc
JKB wrote:
Je disjoncte... Mais vraiment je disjoncte... J'ai un programme de calcul à compiler sous Solaris 10/Sparc en 64 bits.
Ce programme fonctionne parfaitement et compile sans aucun problème en 32 bits sur la machine en question (compilateur gcc/gfortran 4.3.2 + GNU ld correspondant).
C'est de la chance, les gens de gcc disent que c'est une mauvaise idée d'utiliser gld sur solaris.
J'arrive à compiler en 64 bits avec la chaîne gcc/Solaris ld. Sauf que cela ne fonctionne pas bien au final car j'ai absolument besoin de l'option -export-dynamic du linker de GNU. J'ai bien essayé de trouver l'équivalent dans les nombreuses options du linker de Solaris, mais rien n'y fait.
C'est surprenant, on lit à un certain nombre d'endroits que c'est le comportement par défaut (sinon un mapfile devrait faire l'affaire).
Ça c'est juste comme d'habitude des specs foireuses de gcc.
J'ai essayé de truander en imposant ce chemin dans les options du linker, rien n'y fait et c'est toujours les version 32 bits qui sont chargées !
Comment ? Avec -rpath ?
JKB wrote:
Je disjoncte... Mais vraiment je disjoncte... J'ai un programme de
calcul à compiler sous Solaris 10/Sparc en 64 bits.
Ce programme fonctionne parfaitement et compile sans aucun problème
en 32 bits sur la machine en question (compilateur gcc/gfortran 4.3.2 +
GNU ld correspondant).
C'est de la chance, les gens de gcc disent que c'est une mauvaise idée
d'utiliser gld sur solaris.
J'arrive à compiler en 64 bits avec la chaîne gcc/Solaris ld. Sauf
que cela ne fonctionne pas bien au final car j'ai absolument besoin de
l'option -export-dynamic du linker de GNU. J'ai bien essayé de trouver
l'équivalent dans les nombreuses options du linker de Solaris, mais rien
n'y fait.
C'est surprenant, on lit à un certain nombre d'endroits que c'est le
comportement par défaut (sinon un mapfile devrait faire l'affaire).
Je disjoncte... Mais vraiment je disjoncte... J'ai un programme de calcul à compiler sous Solaris 10/Sparc en 64 bits.
Ce programme fonctionne parfaitement et compile sans aucun problème en 32 bits sur la machine en question (compilateur gcc/gfortran 4.3.2 + GNU ld correspondant).
C'est de la chance, les gens de gcc disent que c'est une mauvaise idée d'utiliser gld sur solaris.
J'arrive à compiler en 64 bits avec la chaîne gcc/Solaris ld. Sauf que cela ne fonctionne pas bien au final car j'ai absolument besoin de l'option -export-dynamic du linker de GNU. J'ai bien essayé de trouver l'équivalent dans les nombreuses options du linker de Solaris, mais rien n'y fait.
C'est surprenant, on lit à un certain nombre d'endroits que c'est le comportement par défaut (sinon un mapfile devrait faire l'affaire).
Ça c'est juste comme d'habitude des specs foireuses de gcc.
J'ai essayé de truander en imposant ce chemin dans les options du linker, rien n'y fait et c'est toujours les version 32 bits qui sont chargées !
Comment ? Avec -rpath ?
JKB
Le 11-01-2009, ? propos de Re: Compiler un exécutable en 64 bits sous Solaris? avec gcc/gnu-ld, Marc ?crivait dans fr.comp.os.unix :
JKB wrote:
Je disjoncte... Mais vraiment je disjoncte... J'ai un programme de calcul à compiler sous Solaris 10/Sparc en 64 bits.
Ce programme fonctionne parfaitement et compile sans aucun problème en 32 bits sur la machine en question (compilateur gcc/gfortran 4.3.2 + GNU ld correspondant).
C'est de la chance, les gens de gcc disent que c'est une mauvaise idée d'utiliser gld sur solaris.
Sauf qu'il faut pouvoir faire autrement...
J'arrive à compiler en 64 bits avec la chaîne gcc/Solaris ld. Sauf que cela ne fonctionne pas bien au final car j'ai absolument besoin de l'option -export-dynamic du linker de GNU. J'ai bien essayé de trouver l'équivalent dans les nombreuses options du linker de Solaris, mais rien n'y fait.
C'est surprenant, on lit à un certain nombre d'endroits que c'est le comportement par défaut (sinon un mapfile devrait faire l'affaire).
En tout cas, la bibliothèque ne _peut_ utiliser les symboles exportés par le programme la chargeant.
Ça c'est juste comme d'habitude des specs foireuses de gcc.
J'ai essayé de truander en imposant ce chemin dans les options du linker, rien n'y fait et c'est toujours les version 32 bits qui sont chargées !
Comment ? Avec -rpath ?
Oui.
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
Le 11-01-2009, ? propos de
Re: Compiler un exécutable en 64 bits sous Solaris? avec gcc/gnu-ld,
Marc ?crivait dans fr.comp.os.unix :
JKB wrote:
Je disjoncte... Mais vraiment je disjoncte... J'ai un programme de
calcul à compiler sous Solaris 10/Sparc en 64 bits.
Ce programme fonctionne parfaitement et compile sans aucun problème
en 32 bits sur la machine en question (compilateur gcc/gfortran 4.3.2 +
GNU ld correspondant).
C'est de la chance, les gens de gcc disent que c'est une mauvaise idée
d'utiliser gld sur solaris.
Sauf qu'il faut pouvoir faire autrement...
J'arrive à compiler en 64 bits avec la chaîne gcc/Solaris ld. Sauf
que cela ne fonctionne pas bien au final car j'ai absolument besoin de
l'option -export-dynamic du linker de GNU. J'ai bien essayé de trouver
l'équivalent dans les nombreuses options du linker de Solaris, mais rien
n'y fait.
C'est surprenant, on lit à un certain nombre d'endroits que c'est le
comportement par défaut (sinon un mapfile devrait faire l'affaire).
En tout cas, la bibliothèque ne _peut_ utiliser les symboles
exportés par le programme la chargeant.
Ça c'est juste comme d'habitude des specs foireuses de gcc.
J'ai essayé de truander en imposant ce chemin dans les options du
linker, rien n'y fait et c'est toujours les version 32 bits qui sont
chargées !
Comment ? Avec -rpath ?
Oui.
JKB
--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.
Le 11-01-2009, ? propos de Re: Compiler un exécutable en 64 bits sous Solaris? avec gcc/gnu-ld, Marc ?crivait dans fr.comp.os.unix :
JKB wrote:
Je disjoncte... Mais vraiment je disjoncte... J'ai un programme de calcul à compiler sous Solaris 10/Sparc en 64 bits.
Ce programme fonctionne parfaitement et compile sans aucun problème en 32 bits sur la machine en question (compilateur gcc/gfortran 4.3.2 + GNU ld correspondant).
C'est de la chance, les gens de gcc disent que c'est une mauvaise idée d'utiliser gld sur solaris.
Sauf qu'il faut pouvoir faire autrement...
J'arrive à compiler en 64 bits avec la chaîne gcc/Solaris ld. Sauf que cela ne fonctionne pas bien au final car j'ai absolument besoin de l'option -export-dynamic du linker de GNU. J'ai bien essayé de trouver l'équivalent dans les nombreuses options du linker de Solaris, mais rien n'y fait.
C'est surprenant, on lit à un certain nombre d'endroits que c'est le comportement par défaut (sinon un mapfile devrait faire l'affaire).
En tout cas, la bibliothèque ne _peut_ utiliser les symboles exportés par le programme la chargeant.
Ça c'est juste comme d'habitude des specs foireuses de gcc.
J'ai essayé de truander en imposant ce chemin dans les options du linker, rien n'y fait et c'est toujours les version 32 bits qui sont chargées !
Comment ? Avec -rpath ?
Oui.
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
Marc
JKB wrote:
En tout cas, la bibliothèque ne _peut_ utiliser les symboles exportés par le programme la chargeant.
Je viens d'essayer, et j'y arrive sans aucune difficulté (gcc-3.4 utilisant le ld de Sun sur solaris 9). Il va falloir donner plus de détails...
J'ai essayé de truander en imposant ce chemin dans les options du linker, rien n'y fait et c'est toujours les version 32 bits qui sont chargées !
Comment ? Avec -rpath ?
Oui.
Que donne dump -Lv sur le résultat ? Et qu'affiche gfortran -v pour le link ?
JKB wrote:
En tout cas, la bibliothèque ne _peut_ utiliser les symboles
exportés par le programme la chargeant.
Je viens d'essayer, et j'y arrive sans aucune difficulté (gcc-3.4
utilisant le ld de Sun sur solaris 9). Il va falloir donner plus de
détails...
J'ai essayé de truander en imposant ce chemin dans les options du
linker, rien n'y fait et c'est toujours les version 32 bits qui sont
chargées !
Comment ? Avec -rpath ?
Oui.
Que donne dump -Lv sur le résultat ? Et qu'affiche gfortran -v pour le
link ?
En tout cas, la bibliothèque ne _peut_ utiliser les symboles exportés par le programme la chargeant.
Je viens d'essayer, et j'y arrive sans aucune difficulté (gcc-3.4 utilisant le ld de Sun sur solaris 9). Il va falloir donner plus de détails...
J'ai essayé de truander en imposant ce chemin dans les options du linker, rien n'y fait et c'est toujours les version 32 bits qui sont chargées !
Comment ? Avec -rpath ?
Oui.
Que donne dump -Lv sur le résultat ? Et qu'affiche gfortran -v pour le link ?
JKB
Le 11-01-2009, ? propos de Re: Compiler un exécutable en 64 bits sous? Solaris? avec gcc/gnu-ld, Marc ?crivait dans fr.comp.os.unix :
JKB wrote:
En tout cas, la bibliothèque ne _peut_ utiliser les symboles exportés par le programme la chargeant.
Je viens d'essayer, et j'y arrive sans aucune difficulté (gcc-3.4 utilisant le ld de Sun sur solaris 9). Il va falloir donner plus de détails...
Il n'y a pas de gfortran avec gcc-3.4 ;-)
J'ai essayé de truander en imposant ce chemin dans les options du linker, rien n'y fait et c'est toujours les version 32 bits qui sont chargées !
Comment ? Avec -rpath ?
Oui.
Que donne dump -Lv sur le résultat ? Et qu'affiche gfortran -v pour le link ?
Il faudrait que je reteste, mais je n'ai pas de machine de test disponible tout de suite.
Cordialement,
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
Le 11-01-2009, ? propos de
Re: Compiler un exécutable en 64 bits sous? Solaris? avec gcc/gnu-ld,
Marc ?crivait dans fr.comp.os.unix :
JKB wrote:
En tout cas, la bibliothèque ne _peut_ utiliser les symboles
exportés par le programme la chargeant.
Je viens d'essayer, et j'y arrive sans aucune difficulté (gcc-3.4
utilisant le ld de Sun sur solaris 9). Il va falloir donner plus de
détails...
Il n'y a pas de gfortran avec gcc-3.4 ;-)
J'ai essayé de truander en imposant ce chemin dans les options du
linker, rien n'y fait et c'est toujours les version 32 bits qui sont
chargées !
Comment ? Avec -rpath ?
Oui.
Que donne dump -Lv sur le résultat ? Et qu'affiche gfortran -v pour le
link ?
Il faudrait que je reteste, mais je n'ai pas de machine de test
disponible tout de suite.
Cordialement,
JKB
--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.
Le 11-01-2009, ? propos de Re: Compiler un exécutable en 64 bits sous? Solaris? avec gcc/gnu-ld, Marc ?crivait dans fr.comp.os.unix :
JKB wrote:
En tout cas, la bibliothèque ne _peut_ utiliser les symboles exportés par le programme la chargeant.
Je viens d'essayer, et j'y arrive sans aucune difficulté (gcc-3.4 utilisant le ld de Sun sur solaris 9). Il va falloir donner plus de détails...
Il n'y a pas de gfortran avec gcc-3.4 ;-)
J'ai essayé de truander en imposant ce chemin dans les options du linker, rien n'y fait et c'est toujours les version 32 bits qui sont chargées !
Comment ? Avec -rpath ?
Oui.
Que donne dump -Lv sur le résultat ? Et qu'affiche gfortran -v pour le link ?
Il faudrait que je reteste, mais je n'ai pas de machine de test disponible tout de suite.
Cordialement,
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
