Bonsoir,
(Je suis débutant et viens de fr.comp.lang.c où on m'a dis de venir ici,
si ce n'est pas le bon endroit pour cette question, merci de m'indiquer le
forum approprié.)
Je souhaite compiler une application pour l'exécuter en CGI sur un serveur.
Lorsque je la compile en dynamique une librairie ne correspond pas :
./test: /lib/libc.so.6: version `GLIBC_2.3' not found (required by ./test)
./test: /lib/libc.so.6: version `GLIBC_2.2' not found (required by ./test)
J'ai donc essayé en compilant en -static (j'ai vu que d'autres cgi installés
sur le serveur étaient compilés en static également), mais j'obtiens en
message d'erreur :
Illegal instruction
Sauriez-vous comment je peux résoudre ce problème ?
Dois-je récupérer le fichier /lib/libc.so.6 du serveur et tenter de linker
avec en local ? Si oui comment fait-on cela ?
Ou sauriez-vous ce qui est à l'origine de l'erreur "Illegal instruction" ?
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
Harpo
Florent Monnier wrote:
Bonsoir, (Je suis débutant et viens de fr.comp.lang.c où on m'a dis de venir ici, si ce n'est pas le bon endroit pour cette question, merci de m'indiquer le forum approprié.)
Je souhaite compiler une application pour l'exécuter en CGI sur un serveur. Lorsque je la compile en dynamique une librairie ne correspond pas : ./test: /lib/libc.so.6: version `GLIBC_2.3' not found (required by ./test) ./test: /lib/libc.so.6: version `GLIBC_2.2' not found (required by ./test)
Ta version de distribution n'est pas compatible avec celle du serveur, la solution est de faire en sorte qu'elles le soient, probablement en installant sur ta machine de développement la même distribution que le serveur.
J'ai donc essayé en compilant en -static (j'ai vu que d'autres cgi installés sur le serveur étaient compilés en static également), mais j'obtiens en message d'erreur : Illegal instruction
Sauriez-vous comment je peux résoudre ce problème ?
C'est un code opération 'machine' qui n'est pas supporté par le processeur. Ton programme ou plus vraisemblablement les librairies que tu utilisent pour développer ont été compilées pour un type de processeur qui a des instructions que n'a pas celui du serveur, par exemple un i686 alors que celui du serveur est un i386 Pour connaitre le processeur de la machine $ uname -m fait carrément $ uname -a
La encore, la solution est d'avoir le même environnement que la machine cible.
Dois-je récupérer le fichier /lib/libc.so.6 du serveur et tenter de linker avec en local ? Si oui comment fait-on cela ?
Avec GCC, par exemple en prenant les objets et les libs en entrée.
Mais la solution est plutot d'installer la même distribution que le serveur sur une partition.
Florent Monnier wrote:
Bonsoir,
(Je suis débutant et viens de fr.comp.lang.c où on m'a dis de venir
ici, si ce n'est pas le bon endroit pour cette question, merci de
m'indiquer le forum approprié.)
Je souhaite compiler une application pour l'exécuter en CGI sur un
serveur. Lorsque je la compile en dynamique une librairie ne
correspond pas : ./test: /lib/libc.so.6: version `GLIBC_2.3' not found
(required by ./test) ./test: /lib/libc.so.6: version `GLIBC_2.2' not
found (required by ./test)
Ta version de distribution n'est pas compatible avec celle du serveur,
la solution est de faire en sorte qu'elles le soient, probablement en
installant sur ta machine de développement la même distribution que le
serveur.
J'ai donc essayé en compilant en -static (j'ai vu que d'autres cgi
installés sur le serveur étaient compilés en static également), mais
j'obtiens en message d'erreur :
Illegal instruction
Sauriez-vous comment je peux résoudre ce problème ?
C'est un code opération 'machine' qui n'est pas supporté par le
processeur.
Ton programme ou plus vraisemblablement les librairies que tu utilisent
pour développer ont été compilées pour un type de processeur qui a des
instructions que n'a pas celui du serveur, par exemple un i686 alors
que celui du serveur est un i386
Pour connaitre le processeur de la machine
$ uname -m
fait carrément
$ uname -a
La encore, la solution est d'avoir le même environnement que la machine
cible.
Dois-je récupérer le fichier /lib/libc.so.6 du serveur et tenter de
linker avec en local ? Si oui comment fait-on cela ?
Avec GCC, par exemple en prenant les objets et les libs en entrée.
Mais la solution est plutot d'installer la même distribution que le
serveur sur une partition.
Bonsoir, (Je suis débutant et viens de fr.comp.lang.c où on m'a dis de venir ici, si ce n'est pas le bon endroit pour cette question, merci de m'indiquer le forum approprié.)
Je souhaite compiler une application pour l'exécuter en CGI sur un serveur. Lorsque je la compile en dynamique une librairie ne correspond pas : ./test: /lib/libc.so.6: version `GLIBC_2.3' not found (required by ./test) ./test: /lib/libc.so.6: version `GLIBC_2.2' not found (required by ./test)
Ta version de distribution n'est pas compatible avec celle du serveur, la solution est de faire en sorte qu'elles le soient, probablement en installant sur ta machine de développement la même distribution que le serveur.
J'ai donc essayé en compilant en -static (j'ai vu que d'autres cgi installés sur le serveur étaient compilés en static également), mais j'obtiens en message d'erreur : Illegal instruction
Sauriez-vous comment je peux résoudre ce problème ?
C'est un code opération 'machine' qui n'est pas supporté par le processeur. Ton programme ou plus vraisemblablement les librairies que tu utilisent pour développer ont été compilées pour un type de processeur qui a des instructions que n'a pas celui du serveur, par exemple un i686 alors que celui du serveur est un i386 Pour connaitre le processeur de la machine $ uname -m fait carrément $ uname -a
La encore, la solution est d'avoir le même environnement que la machine cible.
Dois-je récupérer le fichier /lib/libc.so.6 du serveur et tenter de linker avec en local ? Si oui comment fait-on cela ?
Avec GCC, par exemple en prenant les objets et les libs en entrée.
Mais la solution est plutot d'installer la même distribution que le serveur sur une partition.
Florent Monnier
C'est un code opération 'machine' qui n'est pas supporté par le processeur. Ton programme ou plus vraisemblablement les librairies que tu utilisent pour développer ont été compilées pour un type de processeur qui a des instructions que n'a pas celui du serveur, par exemple un i686 alors que celui du serveur est un i386
Pour connaitre le processeur de la machine $ uname -m fait carrément $ uname -a
[ ~]$ uname -m i686 [ ~]$ uname -a Linux localhost 2.6.12-12mdk #1 Fri Sep 9 18:15:22 CEST 2005 i686 Intel(R) Pentium(R) 4 CPU 2.40GHz unknown GNU/Linux [ ~]$ ssh *****.org ******.org's password: Last login: Thu Apr 6 20:08:00 2006 Linux 2.2.19. :~$ uname -m i686 :~$ uname -a Linux tuxinette 2.2.19 #3 SMP Wed Apr 3 15:15:11 CEST 2002 i686 unknown
La encore, la solution est d'avoir le même environnement que la machine cible.
Je ne sais pas ce que c'est comme machine cible, (je vais demander à la personne)
Et si j'installe juste un noyau 2.2.19, ça le ferait ?
Dois-je récupérer le fichier /lib/libc.so.6 du serveur et tenter de linker avec en local ? Si oui comment fait-on cela ?
Avec GCC, par exemple en prenant les objets et les libs en entrée.
pourriez-vous m'indiquer les options qui permettent de réaliser cela ?
Mais la solution est plutot d'installer la même distribution que le serveur sur une partition.
à défaut, est-ce que un gros scp bien bourrin de :/usr/lib, etc, dans /opt puis un chroot sur /opt aurait des chances d'être une solution à peu prêt fonctionnelle ?
Ou alors n'y aurai-il pas moyen de compiler en demandant à gcc de produire un binaire compatible i386 ? (y a-t-il un forum dédié à gcc ?)
--
C'est un code opération 'machine' qui n'est pas supporté par le
processeur.
Ton programme ou plus vraisemblablement les librairies que tu utilisent
pour développer ont été compilées pour un type de processeur qui a des
instructions que n'a pas celui du serveur, par exemple un i686 alors
que celui du serveur est un i386
Pour connaitre le processeur de la machine
$ uname -m
fait carrément
$ uname -a
[blue_prawn@localhost ~]$ uname -m
i686
[blue_prawn@localhost ~]$ uname -a
Linux localhost 2.6.12-12mdk #1 Fri Sep 9 18:15:22 CEST 2005 i686 Intel(R)
Pentium(R) 4 CPU 2.40GHz unknown GNU/Linux
[blue_prawn@localhost ~]$ ssh blue_prawn@linux-*****.org
blue_prawn@linux-******.org's password:
Last login: Thu Apr 6 20:08:00 2006
Linux 2.2.19.
blue_prawn@tuxinette:~$ uname -m
i686
blue_prawn@tuxinette:~$ uname -a
Linux tuxinette 2.2.19 #3 SMP Wed Apr 3 15:15:11 CEST 2002 i686 unknown
La encore, la solution est d'avoir le même environnement que la machine
cible.
Je ne sais pas ce que c'est comme machine cible,
(je vais demander à la personne)
Et si j'installe juste un noyau 2.2.19, ça le ferait ?
Dois-je récupérer le fichier /lib/libc.so.6 du serveur et tenter de
linker avec en local ? Si oui comment fait-on cela ?
Avec GCC, par exemple en prenant les objets et les libs en entrée.
pourriez-vous m'indiquer les options qui permettent de réaliser cela ?
Mais la solution est plutot d'installer la même distribution que le
serveur sur une partition.
à défaut, est-ce que un gros scp bien bourrin de me@host:/usr/lib, etc,
dans /opt puis un chroot sur /opt aurait des chances d'être une solution à
peu prêt fonctionnelle ?
Ou alors n'y aurai-il pas moyen de compiler en demandant à gcc de produire
un binaire compatible i386 ?
(y a-t-il un forum dédié à gcc ?)
C'est un code opération 'machine' qui n'est pas supporté par le processeur. Ton programme ou plus vraisemblablement les librairies que tu utilisent pour développer ont été compilées pour un type de processeur qui a des instructions que n'a pas celui du serveur, par exemple un i686 alors que celui du serveur est un i386
Pour connaitre le processeur de la machine $ uname -m fait carrément $ uname -a
[ ~]$ uname -m i686 [ ~]$ uname -a Linux localhost 2.6.12-12mdk #1 Fri Sep 9 18:15:22 CEST 2005 i686 Intel(R) Pentium(R) 4 CPU 2.40GHz unknown GNU/Linux [ ~]$ ssh *****.org ******.org's password: Last login: Thu Apr 6 20:08:00 2006 Linux 2.2.19. :~$ uname -m i686 :~$ uname -a Linux tuxinette 2.2.19 #3 SMP Wed Apr 3 15:15:11 CEST 2002 i686 unknown
La encore, la solution est d'avoir le même environnement que la machine cible.
Je ne sais pas ce que c'est comme machine cible, (je vais demander à la personne)
Et si j'installe juste un noyau 2.2.19, ça le ferait ?
Dois-je récupérer le fichier /lib/libc.so.6 du serveur et tenter de linker avec en local ? Si oui comment fait-on cela ?
Avec GCC, par exemple en prenant les objets et les libs en entrée.
pourriez-vous m'indiquer les options qui permettent de réaliser cela ?
Mais la solution est plutot d'installer la même distribution que le serveur sur une partition.
à défaut, est-ce que un gros scp bien bourrin de :/usr/lib, etc, dans /opt puis un chroot sur /opt aurait des chances d'être une solution à peu prêt fonctionnelle ?
Ou alors n'y aurai-il pas moyen de compiler en demandant à gcc de produire un binaire compatible i386 ? (y a-t-il un forum dédié à gcc ?)
--
Gilles Civario
Florent Monnier wrote:
Bonsoir, (Je suis débutant et viens de fr.comp.lang.c où on m'a dis de venir ici, si ce n'est pas le bon endroit pour cette question, merci de m'indiquer le forum approprié.)
Je souhaite compiler une application pour l'exécuter en CGI sur un serveur. Lorsque je la compile en dynamique une librairie ne correspond pas : ./test: /lib/libc.so.6: version `GLIBC_2.3' not found (required by ./test) ./test: /lib/libc.so.6: version `GLIBC_2.2' not found (required by ./test)
Au hasard : essaye export LD_ASSUME_KERNEL=2.2 avant de lancer ton code ...
Gilles
Florent Monnier wrote:
Bonsoir,
(Je suis débutant et viens de fr.comp.lang.c où on m'a dis de venir ici,
si ce n'est pas le bon endroit pour cette question, merci de m'indiquer le
forum approprié.)
Je souhaite compiler une application pour l'exécuter en CGI sur un serveur.
Lorsque je la compile en dynamique une librairie ne correspond pas :
./test: /lib/libc.so.6: version `GLIBC_2.3' not found (required by ./test)
./test: /lib/libc.so.6: version `GLIBC_2.2' not found (required by ./test)
Au hasard : essaye export LD_ASSUME_KERNEL=2.2 avant de lancer ton code ...
Bonsoir, (Je suis débutant et viens de fr.comp.lang.c où on m'a dis de venir ici, si ce n'est pas le bon endroit pour cette question, merci de m'indiquer le forum approprié.)
Je souhaite compiler une application pour l'exécuter en CGI sur un serveur. Lorsque je la compile en dynamique une librairie ne correspond pas : ./test: /lib/libc.so.6: version `GLIBC_2.3' not found (required by ./test) ./test: /lib/libc.so.6: version `GLIBC_2.2' not found (required by ./test)
Au hasard : essaye export LD_ASSUME_KERNEL=2.2 avant de lancer ton code ...
Gilles
Benoit SIBAUD
Je souhaite compiler une application pour l'exécuter en CGI sur un serveur. Lorsque je la compile en dynamique une librairie ne correspond pas : ../test: /lib/libc.so.6: version `GLIBC_2.3' not found (required by ./test) ../test: /lib/libc.so.6: version `GLIBC_2.2' not found (required by ./test)
Et sinon ce n'est pas une bonne idée de nommer un binaire 'test', à cause de /usr/bin/test. Si on se trompe en appelant test au lieu de ./test, on peut s'arracher les cheveux quelques temps avant de comprendre le souci.
-- Benoît Sibaud
Je souhaite compiler une application pour l'exécuter en CGI sur un serveur.
Lorsque je la compile en dynamique une librairie ne correspond pas :
../test: /lib/libc.so.6: version `GLIBC_2.3' not found (required by ./test)
../test: /lib/libc.so.6: version `GLIBC_2.2' not found (required by ./test)
Et sinon ce n'est pas une bonne idée de nommer un binaire 'test', à
cause de /usr/bin/test. Si on se trompe en appelant test au lieu de
./test, on peut s'arracher les cheveux quelques temps avant de
comprendre le souci.
Je souhaite compiler une application pour l'exécuter en CGI sur un serveur. Lorsque je la compile en dynamique une librairie ne correspond pas : ../test: /lib/libc.so.6: version `GLIBC_2.3' not found (required by ./test) ../test: /lib/libc.so.6: version `GLIBC_2.2' not found (required by ./test)
Et sinon ce n'est pas une bonne idée de nommer un binaire 'test', à cause de /usr/bin/test. Si on se trompe en appelant test au lieu de ./test, on peut s'arracher les cheveux quelques temps avant de comprendre le souci.
-- Benoît Sibaud
Florent Monnier
Au hasard : essaye export LD_ASSUME_KERNEL=2.2 avant de lancer ton code
:~$ export LD_ASSUME_KERNEL=2.2 :~$ ./grcta ./grcta: /lib/libc.so.6: version `GLIBC_2.3' not found (required by ./grcta) ./grcta: /lib/libc.so.6: version `GLIBC_2.2' not found (required by ./grcta)
--
Au hasard : essaye export LD_ASSUME_KERNEL=2.2 avant de lancer ton code
blue_prawn@tux:~$ export LD_ASSUME_KERNEL=2.2
blue_prawn@tux:~$ ./grcta
./grcta: /lib/libc.so.6: version `GLIBC_2.3' not found (required by ./grcta)
./grcta: /lib/libc.so.6: version `GLIBC_2.2' not found (required by ./grcta)
Au hasard : essaye export LD_ASSUME_KERNEL=2.2 avant de lancer ton code
:~$ export LD_ASSUME_KERNEL=2.2 :~$ ./grcta ./grcta: /lib/libc.so.6: version `GLIBC_2.3' not found (required by ./grcta) ./grcta: /lib/libc.so.6: version `GLIBC_2.2' not found (required by ./grcta)
--
Florent Monnier
Ou alors n'y aurai-il pas moyen de compiler en demandant à gcc de produire un binaire compatible i386 ?
avec gcc -mcpu=i386 -static j'ai toujours 'Illegal instruction' comme message d'erreur quand je lance le cgi sur le serveur.
Ou alors n'y aurai-il pas moyen de compiler en demandant à gcc de produire
un binaire compatible i386 ?
avec gcc -mcpu=i386 -static j'ai toujours 'Illegal instruction' comme
message d'erreur quand je lance le cgi sur le serveur.
Ou alors n'y aurai-il pas moyen de compiler en demandant à gcc de produire un binaire compatible i386 ?
avec gcc -mcpu=i386 -static j'ai toujours 'Illegal instruction' comme message d'erreur quand je lance le cgi sur le serveur.
Harpo
Florent Monnier wrote:
Ou alors n'y aurai-il pas moyen de compiler en demandant à gcc de produire un binaire compatible i386 ?
avec gcc -mcpu=i386 -static j'ai toujours 'Illegal instruction' comme message d'erreur quand je lance le cgi sur le serveur.
Le problème ne vient sans doute pas de ton code mais de celui d'une librairie qui a été compilée pour un autre materiel et avec laquelle tu a linké ton programme.
Florent Monnier wrote:
Ou alors n'y aurai-il pas moyen de compiler en demandant à gcc de
produire un binaire compatible i386 ?
avec gcc -mcpu=i386 -static j'ai toujours 'Illegal instruction' comme
message d'erreur quand je lance le cgi sur le serveur.
Le problème ne vient sans doute pas de ton code mais de celui d'une
librairie qui a été compilée pour un autre materiel et avec laquelle tu
a linké ton programme.
Ou alors n'y aurai-il pas moyen de compiler en demandant à gcc de produire un binaire compatible i386 ?
avec gcc -mcpu=i386 -static j'ai toujours 'Illegal instruction' comme message d'erreur quand je lance le cgi sur le serveur.
Le problème ne vient sans doute pas de ton code mais de celui d'une librairie qui a été compilée pour un autre materiel et avec laquelle tu a linké ton programme.
Harpo
Florent Monnier wrote:
[ ~]$ uname -a Linux localhost 2.6.12-12mdk #1 Fri Sep 9 18:15:22 CEST 2005 i686 Intel(R) Pentium(R) 4 CPU 2.40GHz unknown GNU/Linux
:~$ uname -a Linux tuxinette 2.2.19 #3 SMP Wed Apr 3 15:15:11 CEST 2002 i686 unknown
Ils ont trouvé le kernel chez un antiquaire ? Ce qui est étonnant, c'est que les 2 disent i686.
Et si j'installe juste un noyau 2.2.19, ça le ferait ?
Je ne pense pas que ce soit en rapport avec le kernel mais je peux me tromper.
Avec GCC, par exemple en prenant les objets et les libs en entrée.
pourriez-vous m'indiquer les options qui permettent de réaliser cela ?
Tu mets les même options que celles que tu emploies pour linker d'habitude, si tu compiles et linke dans la même exécution de gcc tu mets les mêmes options. tu spécifie les .o au lieu des .c sur la ligne de commande. Sauf erreur, ça devrait le faire.
Mais la solution est plutot d'installer la même distribution que le serveur sur une partition.
à défaut, est-ce que un gros scp bien bourrin de :/usr/lib, etc, dans /opt puis un chroot sur /opt aurait des chances d'être une solution à peu prêt fonctionnelle ?
Il faudrait aussi que les autres programmes dont tu as besoin, gcc etc. y soient. A moins que tout soit linké statiquement chez toi, tu ne peux mettre les tiens.
Ou alors n'y aurai-il pas moyen de compiler en demandant à gcc de produire un binaire compatible i386 ?
Oui, je crois d'ailleurs que c'est le défaut. Mais le problème vient probablement des librairies, les downloader toutes et les recompiler est un peu gros.
(y a-t-il un forum dédié à gcc ?)
Sous fr.comp.*, je ne crois pas, mais il y a des forums sur comp.*
Quand je disais qu'il fallait te mettre au niveau du serveur, je faisais peut-être une erreur, c'est plutôt le serveur qu'il faudrait mettre à niveau. Il serait peut-être temps de tout réinstaller sur une distribution récente et saine facile à upgrader (je suggère une distrib Debian Sarge et installer un kernel 2.6.15).
Florent Monnier wrote:
[blue_prawn@localhost ~]$ uname -a
Linux localhost 2.6.12-12mdk #1 Fri Sep 9 18:15:22 CEST 2005 i686
Intel(R) Pentium(R) 4 CPU 2.40GHz unknown GNU/Linux
blue_prawn@tuxinette:~$ uname -a
Linux tuxinette 2.2.19 #3 SMP Wed Apr 3 15:15:11 CEST 2002 i686
unknown
Ils ont trouvé le kernel chez un antiquaire ?
Ce qui est étonnant, c'est que les 2 disent i686.
Et si j'installe juste un noyau 2.2.19, ça le ferait ?
Je ne pense pas que ce soit en rapport avec le kernel mais je peux me
tromper.
Avec GCC, par exemple en prenant les objets et les libs en entrée.
pourriez-vous m'indiquer les options qui permettent de réaliser cela ?
Tu mets les même options que celles que tu emploies pour linker
d'habitude, si tu compiles et linke dans la même exécution de gcc tu
mets les mêmes options. tu spécifie les .o au lieu des .c sur la ligne
de commande.
Sauf erreur, ça devrait le faire.
Mais la solution est plutot d'installer la même distribution que le
serveur sur une partition.
à défaut, est-ce que un gros scp bien bourrin de me@host:/usr/lib,
etc, dans /opt puis un chroot sur /opt aurait des chances d'être une
solution à peu prêt fonctionnelle ?
Il faudrait aussi que les autres programmes dont tu as besoin, gcc etc.
y soient.
A moins que tout soit linké statiquement chez toi, tu ne peux mettre les
tiens.
Ou alors n'y aurai-il pas moyen de compiler en demandant à gcc de
produire un binaire compatible i386 ?
Oui, je crois d'ailleurs que c'est le défaut. Mais le problème vient
probablement des librairies, les downloader toutes et les recompiler
est un peu gros.
(y a-t-il un forum dédié à gcc ?)
Sous fr.comp.*, je ne crois pas, mais il y a des forums sur comp.*
Quand je disais qu'il fallait te mettre au niveau du serveur, je faisais
peut-être une erreur, c'est plutôt le serveur qu'il faudrait mettre à
niveau. Il serait peut-être temps de tout réinstaller sur une
distribution récente et saine facile à upgrader (je suggère une distrib
Debian Sarge et installer un kernel 2.6.15).
[ ~]$ uname -a Linux localhost 2.6.12-12mdk #1 Fri Sep 9 18:15:22 CEST 2005 i686 Intel(R) Pentium(R) 4 CPU 2.40GHz unknown GNU/Linux
:~$ uname -a Linux tuxinette 2.2.19 #3 SMP Wed Apr 3 15:15:11 CEST 2002 i686 unknown
Ils ont trouvé le kernel chez un antiquaire ? Ce qui est étonnant, c'est que les 2 disent i686.
Et si j'installe juste un noyau 2.2.19, ça le ferait ?
Je ne pense pas que ce soit en rapport avec le kernel mais je peux me tromper.
Avec GCC, par exemple en prenant les objets et les libs en entrée.
pourriez-vous m'indiquer les options qui permettent de réaliser cela ?
Tu mets les même options que celles que tu emploies pour linker d'habitude, si tu compiles et linke dans la même exécution de gcc tu mets les mêmes options. tu spécifie les .o au lieu des .c sur la ligne de commande. Sauf erreur, ça devrait le faire.
Mais la solution est plutot d'installer la même distribution que le serveur sur une partition.
à défaut, est-ce que un gros scp bien bourrin de :/usr/lib, etc, dans /opt puis un chroot sur /opt aurait des chances d'être une solution à peu prêt fonctionnelle ?
Il faudrait aussi que les autres programmes dont tu as besoin, gcc etc. y soient. A moins que tout soit linké statiquement chez toi, tu ne peux mettre les tiens.
Ou alors n'y aurai-il pas moyen de compiler en demandant à gcc de produire un binaire compatible i386 ?
Oui, je crois d'ailleurs que c'est le défaut. Mais le problème vient probablement des librairies, les downloader toutes et les recompiler est un peu gros.
(y a-t-il un forum dédié à gcc ?)
Sous fr.comp.*, je ne crois pas, mais il y a des forums sur comp.*
Quand je disais qu'il fallait te mettre au niveau du serveur, je faisais peut-être une erreur, c'est plutôt le serveur qu'il faudrait mettre à niveau. Il serait peut-être temps de tout réinstaller sur une distribution récente et saine facile à upgrader (je suggère une distrib Debian Sarge et installer un kernel 2.6.15).
