Journal Probleme en C insoluble

Posté par  (site web personnel) .
Étiquettes : aucune
0
3
juil.
2003
Lut journal,

Voila, j'ai essayé de compiler un petit programme très simple sur mon bi processor 800, et celui-ci ne compile pas ;(

Mettant bien pris la tete dessus, et ayant demandé conseil à plusieurs personnes qui n'ont pas su me répondre, je commence à desesperer.

Dans sa forme, le programme ressemble à ça:
#include <stdio.h>
#include <asm/smp.h>

int main() {
#ifdef CONFIG_SMP
fprintf(stdout, "yeah");
#endif
exit (0);
}

smp.h utilise le fichier <linux/config.h>.


Le probleme c'est que lorsque CONFIG_SMP n'est pas définit, ça compile.

Lorsqu'il est défini à 1, ça ne compile pas (il faut qu'il soit 1 pour les bi procs):

In file included from /usr/include/asm/smp.h:17,
from plouf.c:2:
/usr/include/asm/fixmap.h:80: error: parse error before "pgprot_t"

In file included from /usr/include/asm/smp.h:21,
from plouf.c:2:
/usr/include/asm/apic.h:85: error: parse error before "unsigned"

Je n'ai pas touché au code de fixmap.h, ni apic.h, voila les deux lignes incréminées:

extern void __set_fixmap (enum fixed_addresses idx, unsigned long phys, pgprot_t flags);

extern struct pm_dev *apic_pm_register(pm_dev_t, unsigned long, pm_callback);

Alors une idée ?
  • # Re: Probleme en C insoluble

    Posté par  . Évalué à 1.

    Je crois bien que le problème est dû à gcc 3.3. Avec cette version la syntaxe des typedef a changé, et donc ça compile pas : http://www.gnu.org/software/gcc/gcc-3.3/changes.html . Faudrait essayer avec gcc 3.2
    • [^] # Re: Probleme en C insoluble

      Posté par  (site web personnel) . Évalué à 1.

      Le probleme c'est que j'étais hier en gcc 3.2, et je me suis dis la meme chose mais dans le sens inverse. J'ai donc migré en gcc 3.3 dans la nuit. Mais ça ne changeait rien avec les deux gcc le probleme etait le meme ;( Est ce que ça peut pas venir des parametres que je passe à gcc, car je fais un simple gcc -o plouf plouf.c ?
      • [^] # Re: Probleme en C insoluble

        Posté par  (site web personnel) . Évalué à -1.

        plouf, plouf(.c). Une souris verte, qui courrait dans l'herbe, je l'attrape par la queue, je la montre à ces messieurs. Ces messieurs me disent: "trempez-la dans l'eau, trempez-la dans l'huile, ça fera un escargot tout chaud" !!! C'est toi qui t'y colle!
    • [^] # Re: Probleme en C insoluble

      Posté par  . Évalué à 1.

      non en fait c'est une nouvelle syntaxe qui avait ete introduite et qui a ete supprime. Apparemment elle n'etait pas vraiment utilisee.
  • # Re: Probleme en C insoluble

    Posté par  . Évalué à 2.

    quelle version de kernel ? et comment du utilises CONFIG_SMP ? gcc -DCONFIG_SMP ?
  • # Re: Probleme en C insoluble

    Posté par  . Évalué à 1.

    au risque de paraitre con : je vois pas ce que tu essaies de faire ... CONFIG_SMP est-juste la pour te dire que ton noyau supporte le SMP et donc que ton programme pourrait, si il est multithread, en profiter. De mon point de vue tu n'as pas a modifier CONFIG_SMP.
    • [^] # Re: Probleme en C insoluble

      Posté par  (site web personnel) . Évalué à 1.

      Lut, Je ne cherche pas a modifier CONFIG_SMP, c'est juste un programme pour réussir à inclure la lib smp.h . Je dois utiliser les fonctions pour multiprocesseur, genre les fonctions smp_processeur_id(). Si tu as des idées, je suis preneur.
      • [^] # Re: Probleme en C insoluble

        Posté par  . Évalué à 1.

        hmmm jamais utilise. mais est-ce que le plus basique des programmes fonctionne ? #include <stdio.h> #include <linux/smp.h> int main(void) { #if defined(CONFIG_SMP) printf("Nombre de processeurs : %d\n", smp_num_cpus); #else print ("Nombre de processeur : 1\n"; #endif return 0; }
        • [^] # Re: Probleme en C insoluble

          Posté par  (site web personnel) . Évalué à 1.

          nope ;) c'est bien ça le probleme, ça me renvoit ça comme erreur: In file included from /usr/include/asm/smp.h:17, from /usr/include/linux/smp.h:14, from plouf2.c:2: /usr/include/asm/fixmap.h:80: error: parse error before "pgprot_t" In file included from /usr/include/asm/smp.h:21, from /usr/include/linux/smp.h:14, from plouf2.c:2: /usr/include/asm/apic.h:85: error: parse error before "unsigned"
          • [^] # Re: Probleme en C insoluble

            Posté par  . Évalué à 1.

            hmmm ca parait bizarre. Si je ne me trompe pas les headers linux/*.h sont generes apres compilation du noyau. normallement tu devrais avoir la definition de :
            . pgprot_t quelque part :)
            il est defini dans noyau-linux/include/asm-i386/page.h tel que
            typedef struct { unsigned long pgprot; } pgprot_t;
            . pm_dev_t dans linux/pm.h qui est inclus par asm/apic.h

            mais je peux pas aider plus comme j'ai pas de config SMP sous la main
            • [^] # Re: Probleme en C insoluble

              Posté par  (site web personnel) . Évalué à 1.

              Ouep, j'ai exactement la meme déclaration pour pgprot_t, et pm_dev_t ;(

              Effectivement, pour le Config_smp, c'est dur de trouver quelqu'un qui l'utilise et qui pourrait faire des tests. Mais hier, j'ai trouvé quelqu'un qui avait le support smp d'activé (avec un seul proc) et il avait la meme erreur de compilation.

              Par contre, on m'a dit qu'en module ça marcherait peut etre ? Je ne sais pas pourquoi, ni comment, mais je vais tester tout à l'heure.

              Merci pour ton coup de main ;)
  • # Re: Probleme en C insoluble

    Posté par  . Évalué à 1.

    J'ai trouvé: Il manque les retours à la ligne ! :-)
  • # Re: Probleme en C insoluble

    Posté par  . Évalué à 1.

    je viens de faire le test sur ma machine (bipro) avec gcc 3.2 et kernel 2.4.20 (version officielle). Au debut cela compilait sans probleme mais CONFIG_SMP n'etait pas defini. J'ai ensuite fait un include de <linux/autoconf.h> et la ca marche.

    Un petit conseil: je ne sais pas ce que tu veux faire mais j'eviterais a ta place le test du SMP via la configuration du noyau linux: ton programme peut etre amene a tourner sous un autre unix. Dans mes codes, je prefere avoir une option externe ou j'indique combien de processeurs le programme doit utiliser. Cela permet en particulier de ne pas squatter toute la puissance de la machine si tu dois la partager. Dans le pire des cas, l'option processeur=1 est traite sans thread.

    Bon courage.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.