problème exécution programme compilé

Bonjour, j'ai récement migré de Redhat4EL vers Centos5 (équivalent de Redat5EL) et je me trouve face à un grave problème de compatibilité. Mes programes C compilés sous Centos5 ne sont pas compatibles avec les systèmes RedHat4 (ou dérivés) ; lorsquej'exécute mon programme compilé sour Centos5 tout fonctionne.
Sous les systèmes plus anciens, j'ai le message suivant : "exeption de point flottant".

ton code est mauvais car tu as utilisé des fonctions ou méthodes "platform-specific".

Un bon code n'est pas forcément un code simple ou un code generant un binaire petit mais un code portable et efficace par définition.

Un code portable, bien écrit donc est tjrs efficace et en plus il est esthétique et facile à comprendre/debugguer...

presentes ton code dans les forum C et demande de l'aide sur les fonctions concernés.

En plus tu commets une très grossière erreur dans ton code :
il génére une erreur avec un message système, que tu n'interceptes pas pour la commenter et donner plus d'info ne serait ce que sur l'endroit du code ou ça plante (au minimum)...

Si tu as plusieurs programmes comme ça .... il va te falloir corriger beaucoup de choses, bon courage.... :aie:


Une piste à envisager, c'est peut etre tout simplement une float à convertir en double ou autre definition de variable ....

Aucun rapport, voici une source simple de prog.c:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13

#include <stdio.h> /* mwmwmwmwmwmwmwmwmwmwm mwmwmwmwmwmwmwmwmwmwmwm mwmwmwmwmwmwmwmwmwmw */ int main(int argc, char *argv[]) { register i = 0;   while (--argc) { printf("%d: %s\n", ++i, *(++argv)); } puts("A tchao ..."); return(0); }

---

je le compile tout simplement sous Centos 5 :

Code:

---

gcc prog.c -o prog.e

---

Je l'exécute sous Centos 5 :

Code:

---

1 2 3

/tmp/prog.e kid 1: kid A tchao ...

---

et lorsque je l'exécute sous un red-hat 4, voila le résultat :

Code:

---

1 2	/tmp/prog.e Exception en point flottant

---

Pourrais-tu mettre les balises de code s'il te plait.

C'est bizarre, t'as écris

Code:

---

register i = 0;

---

au lieu de

Code:

---

register int i =0;

---

et ça marche quand même.

Essaye cette petite modification pour l'instant, car là je ne vois pas
de solution a ton problème.

voila c'est fait

Salut,

pourrais-tu fournir les infos suivantes sur tes deux environnements (CentOS et redhat):

Procésseurs:

Code:

---

1 2	#cat /proc/cpuinfo

---

versions du gcc

Code:

---

1 2	#rpm -qa | grep gcc

---

Compiler ton code avec les options -ansi et -Wall pour voir s'il n'y a pas plus d'infos.

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46

cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 15 model : 4 model name : Intel(R) Xeon(TM) CPU 3.20GHz stepping : 10 cpu MHz : 3192.246 cache size : 2048 KB physical id : 0 siblings : 2 core id : 0 cpu cores : 1 fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 5 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc pni monitor ds_cpl cid cx16 xtpr lahf_lm bogomips : 6387.44   processor : 1 vendor_id : GenuineIntel cpu family : 15 model : 4 model name : Intel(R) Xeon(TM) CPU 3.20GHz stepping : 10 cpu MHz : 3192.246 cache size : 2048 KB physical id : 0 siblings : 2 core id : 0 cpu cores : 1 fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 5 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc pni monitor ds_cpl cid cx16 xtpr lahf_lm bogomips : 6384.07

---

Le problème ne vient pas de la car la machine qui compile n'avait pas le problème avant avec RedHat4.
Cela est surment du a la version de gcc

Voici ce que me retourne ta commande sur la machine qui compile

Code:

---

1 2 3

rpm -qa | grep gcc libgcc-4.1.2-42.el5 gcc-4.1.2-42.el5

---

Et sur la machine qui ne parvient pas à exécuté le programme :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13

rpm -qa | grep gcc gcc-g77-3.4.3-9.EL4 gcc-c++-3.4.3-22.1 compat-libgcc-296-2.96-132.7.2 libgcc-3.4.3-9.EL4 gcc-java-3.4.3-9.EL4 gcc4-c++-4.0.0-0.14.EL4 gcc-3.4.3-22.1 compat-gcc-32-3.2.3-47.3 gcc-3.4.3-9.EL4 gcc4-4.0.0-0.14.EL4 libgcc-3.4.3-22.1 compat-gcc-32-c++-3.2.3-47.3

---

oui peut etre des éléments trop peu portable
comme ton while (--argc) autant il est logique autant c'est cradoc

d'autant plus que tu ne testes jamais rien à aucun moment...
tu ne testes pas sa propre lecture avant le printf par exemple ni si tes variables sont bien valorisées avant des les afficher.

ton i est mal construit en prime ajoutes y un type int ou shortint (je sais plus si short int existe en C)...

pour ce genre de programme c'est sencé n'avoir pas d'incidence mais c'est porcasse....

J'ai perdu l'habitude de coder mais quand même....

vu que c'est le binaire qui ne passe pas d'une machine à l'autre c'est pas un probleme de librairies ou d'install quelconque mais de code.

si en revanche ça arrivait en compilant sur l'autre machine là je veux bien croire à la limite à une possible liaison entre les paquets configurés ou non sur les plateformes.


hypotèse aussi aurais tu tout simplement transmis ton binaire par ftp en oubliant de le faire en mode bin ?
:yaisse2:
c'est con mais je me suis déjà fait avoir avec plus bête que ça encore.... ;)

La compilation avec les option -Wall et -ansi te donne-t-elle des informations supplémentaires?

http://c.developpez.com/tutgcc/c408.php

au premier regard ton code n'as pas l'air mauvais en lui même.

j'arrive à le compiler même sous AIX avec un vieux gcc et des librairies IBM-potentiellement+ou-modifiées

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33

ZAPHOD4:root # cat >> toto.c #include <stdio.h> int main(int argc, char *argv[]) { register i = 0; while (--argc) { printf("%d: %s\n", ++i, *(++argv)); } puts("A tchao ..."); return(0); } ^D ZAPHOD4:root # gcc --version gcc (GCC) 3.3.2 Copyright (C) 2003 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.   ZAPHOD4:root # gcc -O3 -Wall toto.c -o toto toto.c: In function `main': toto.c:4: warning: type defaults to `int' in declaration of `i' ZAPHOD4:root # sed -e "s/\ i\ /\ int\ i\ /" toto.c > toto2.c ZAPHOD4:root # gcc -O3 -Wall toto2.c -o toto ZAPHOD4:root # strip toto ZAPHOD4:root # ./toto df sdfsfn rze 1: df 2: sdfsfn 3: rze A tchao ... ZAPHOD4:root # cd - && rm /tmp/toto* ZAPHOD4:root #

---

mais ça conforte mon hypotèse que les librairies ou version GCC n'ont rien à voir là dedant et que c'est bien le binaire donc le code qui est pas assez portable.

de plus un test de compilation sur la machine ciblé serai bon aussi
afin de valider ou infirmer certaines hypotèses.... :roll:

ça permettrait d'y voir plus clair

fr31, le cobol c'est fini.

J'ai le même problème avec la source suivante :

Code:

---

1 2 3 4

int main(int argc, char *argv[]) { return(0); }

---

Faut-il selon toi effectuer des vérifications dans cette source?

Citation:

---

Envoyé par docteurbunny

fr31, le cobol c'est fini.

---

non d'ailleurs les cobolistes sont les mieux payés actuellement car personne n'en trouve plus et il faut payer pour convaincre les papys de renoncer à la retraite et de bosser pour aider les djeunz à convertir les programmes...

chez 2 de mes clients c'est le cas et chez au moins 11 clients de la boites sur une 20t'aine...même si je suis pas dans la partie codage j'en entand causer...:aie:

--------

quant à ton problème poste ici la copie écran de la compilation sur la cible qu'on voit si dans ce cas ça marche si oui alors c'est bien ton code.

peut etre faire un exit plustot qu'un return....

les option -Wall et -ansi ne changent rien

Pour frp31 ;
tous mes programmes compilées par Centos 5 ne sont pas exécutables par Redhat4
Ces memes souces fonctionnent si elles sont compilés par RedHat4 ; il s'agit manifestement d'un problème de rétrocompatibilité entre les versions de gcc (qui sont différentes.
Je cherche donc à activer une otion dans gcc permettant cela

C'est assez probable oui sinon je vois pas ....

Personne n'a jamais migré un serveur de dévelopement de RedHat4EL vers RedHat5EL; c'est pas possible

Sur la machine où tu ne parviens pas à executer tes programmes.
Je vois plusieurs version de gcc installées.
ça peut certainement poser de problèmes de conflits

Citation:

---

rpm -qa | grep gcc
gcc-g77-3.4.3-9.EL4
gcc-c++-3.4.3-22.1
compat-libgcc-296-2.96-132.7.2
libgcc-3.4.3-9.EL4
gcc-java-3.4.3-9.EL4
gcc4-c++-4.0.0-0.14.EL4
gcc-3.4.3-22.1
compat-gcc-32-3.2.3-47.3
gcc-3.4.3-9.EL4
gcc4-4.0.0-0.14.EL4
libgcc-3.4.3-22.1
compat-gcc-32-c++-3.2.3-47.3

---

Je pense qu'il serait bien de tester en ne laissant qu'une seule version de gcc installée sur ta machine.

J'ai le problème sur une machine en production avec la configuration suivante :

gcc-java-3.4.3-9.EL4
libgcc-3.4.3-9.EL4
gcc-3.4.3-9.EL4
gcc-g77-3.4.3-9.EL4
compat-libgcc-296-2.96-132.7.2
compat-gcc-32-3.2.3-47.3
gcc-c++-3.4.3-9.EL4
compat-gcc-32-c++-3.2.3-47.3

Du nouveau :
Lorsque je compile un programme sur Ubuntu 8.04 qui a gcc-4.1 tout comme Centos5, cela fonctionne sur une machine redhat4 et sur Centos5.
Lorsque je compile un programme sur Centos5 cela me crée un binaire qui fonctionne sur Ubuntu8.04.

Vraiment bizare

Et en retirant les packages compat-*

c'est fait mais cela ne change rien

Ton probleme est certainement lie a l'utilisation de bibliotheque partagees. Essaie d'ajouter -static a tes options de compilation pour voir si ca arrange les choses.

ta solution fonctionne et je t'en remrcie. Cependant elle n'est pas apllicable dans mon contexte ; mes sources génèrent des exécutables utilisés par une application utilisée sur des serveurs en production. L'utilisation des librairies statiques alourdie énormément mes exécutables puisque leur taille est multipliée par 100. Il me faut donc pouvoir utiliser les librairies dynamiques.

Citation:

---

Envoyé par docteurbunny

ta solution fonctionne et je t'en remrcie. Cependant elle n'est pas apllicable dans mon contexte ; mes sources génèrent des exécutables utilisés par une application utilisée sur des serveurs en production. L'utilisation des librairies statiques alourdie énormément mes exécutables puisque leur taille est multipliée par 100. Il me faut donc pouvoir utiliser les librairies dynamiques.

---

Malheureusement, ce n'est surement pas possible. Si -static resout le probleme, c'est que les deux systemes sur lequels tu travailles utilisent des versions differentes et incompatibles des bibliotheques partagees.

C'est de la folie, sur le principe; imagine tu as redhat4, tu évolues vers redhat 5 ( red hat est une distribution commerciale) et tu ne peux plus compiler pour tes clients qui ont des versions antérieures. C'est commercialement invivable pour red hat.

Citation:

---

Envoyé par docteurbunny

C'est de la folie, sur le principe; imagine tu as redhat4, tu évolues vers redhat 5 ( red hat est une distribution commerciale) et tu ne peux plus compiler pour tes clients qui ont des versions antérieures. C'est commercialement invivable pour red hat.

---

Il chargent certainement plusieurs versions d'une meme bibliotheque pour maintenir une compatibilite. Je ne connais pas CentOS, et j'ignore s'ils garantissent que l'ABI est compatible avec RHEL4 et 5. Tu peux utiliser ldd sur tes exec pour voir les bibliotheques partagees qui sont utilisees, leur path et leur adresse. Il est alors peut etre possible de jouer avec LD_LIBRARY_PATH pour pointer vers la version correcte.

Comment puis je changer la variable LD_LIBRAIRY_PATH ??

Salut,

Code:

---

1 2	export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/chemin_vers_lib:/autre_chemin_vers_lib

---

centos est la version libre de red hat qui est exactement pareil que redhat; redhat4=centos4,
redhat5=centos5.

le problème ne vient pas de ld_library_path car après plusieurs tests, je constate que pour certains utilisateurs, j'ai LD_LIBRARY_PATH=$SQLDIR/lib et d'autres n'ont pas cette variable.
ce répertoire et son contenu est identique sur les deux seveurs.
de plus lorsque je compile ma source contenant seulement return 0, cela ne fonctionne pas si elle a été compilée sur red hat 5 alors que cela fonctionne si elle a été compilée sur ubuntu 8.04

lorsque je vais sur ma machine red hat4 avec un programme issue de la suivante :

Code:

---

1 2 3 4

int main(int argc, char *argv[]) { return(0); }

---

Si je fais un ldd sur la machine red hat4 du programme compilé pour chaque environement de compilation, j'ai les résultats suivants :

Code:

---

1 2 3

ldd testredhat4.e libc.so.6 => /lib/tls/libc.so.6 (0x00a4a000) /lib/ld-linux.so.2 (0x00a31000)

---

Code:

---

1 2 3

ldd testubuntu.e libc.so.6 => /lib/tls/libc.so.6 (0x00a4a000) /lib/ld-linux.so.2 (0x00a31000)

---

Code:

---

1 2	ldd testcentos5.e /usr/bin/ldd: line 124: 3077 Exception en point flottant LD_TRACE_LOADED_OBJECTS=1 LD_WARN= LD_BIND_NOW= LD_LIBRARY_VERSION=$verify_out LD_VERBOSE= "$@"

---

Les trois programmes correspondent à la même source mais ont été compilé sur des machines différentes ;

Citation:

---

libc.so.6 => /lib/tls/libc.so.6 (0x00a4a000)

---

/lib/tls/libc.so.6 est-il présent sur la machine générant l'erreur?

la machine qui génère l'erreur (Redhat4EL) possède bien le fichier /lib/tls/libc.so.6

Ok,

peux-tu nous montrer les packages liés à glibc sur chacun de tes environnements? RHEL4,RHEL5 et ubuntu.

Code:

---

1 2	rpm -qa | grep -i glibc

---

voici le résultat de cette commande pour centos5 :

Code:

---

1 2 3 4 5 6 7

rpm -qa|grep glibc glibc-2.5-24 glibc-devel-2.5-24 compat-glibc-headers-2.3.4-2.26 glibc-headers-2.5-24 compat-glibc-2.3.4-2.26 glibc-common-2.5-24

---

Pour RedHat4EL :

Code:

---

1 2 3 4 5

glibc-2.3.4-2 glibc-devel-2.3.4-2 glibc-common-2.3.4-2 glibc-headers-2.3.4-2 glibc-kernheaders-2.4-9.1.87

---

Pour Ubuntu : je n'ai pas trouvé de paquet glibc mais il semblerais que soit la version 2.7

Code:

---

/lib/tls/i686/cmov/libc.so.6 -> libc-2.7.so

---

aparament il faudrait faire de la cross compilation ; quelqu'un y connait quelque chose avec gcc?
Personne n'à une idée svp?

Alors la les kids vous me décevez ; personne trouve alors je répond à cette grande question :
Le nouveau compilateur gcc a changé le format des exécutables ; il compile par défaut avec l'option --ash-style=gnu .Cela entraîne de meilleures performances mais une incompatibilité avec les anciennes version de gcc. Le problème apparaît à partir de la version 4.1 et on peut le résoudre afin d'assurer la rétro compatibilité de la manière suivante :

Code:

---

gcc -Wl,--hash-style=both $source.c -o $executable

---

ou

Code:

---

gcc -Wl,--hash-style=sysv $source.c -o $executable

---

Merci à tout ceux qui se sont penchés sur ce problème