Forum Programmation.c Redefinition of typedef

Posté par  (site web personnel) . Licence CC By‑SA.
Étiquettes : aucune
0
30
déc.
2012

Bonjour à tous !

Je viens demander de l'aide pour un problème de compilation. J'ai un code qui fonctionne sur ma machine, amd64. En essayant de le compiler sur une autre architecture (arm), j'ai le message d'erreur suivant :

/usr/include/poker-eval/poker_defs.h:52:19: error: redefinition of typedef ‘uint64’
/usr/lib/ocaml/caml/config.h:124:26: note: previous declaration of ‘uint64’ was here
/usr/include/poker-eval/poker_defs.h:79:24: error: redefinition of typedef ‘uint32’
/usr/lib/ocaml/caml/config.h:108:22: note: previous declaration of ‘uint32’ was here

Effectivement, chacune des deux librairies cherche à redéfinir les types si ceux-ci ne sont pas présent nativement sur l'architecture. Peut-être existe-t-il une solution simple pour contourner ce problème, mais je ne vois pas trop comment faire…

Cela vous est-il déjà arrivé ?

Merci à vous.

  • # Un problème de macro ?

    Posté par  . Évalué à 3.

    Comment sont faites les définitions de uint32 et uint64 dans les fichiers en questions ?

    Please do not feed the trolls

    • [^] # Re: Un problème de macro ?

      Posté par  (site web personnel) . Évalué à 2. Dernière modification le 30 décembre 2012 à 17:53.

      Elles diffèrent, bien évidement !

      Dans poker_defs.h (le source est ici):

      #undef USE_INT64
      #ifdef HAVE_UINT64_T
      typedef uint64_t        uint64;
      #define USE_INT64 1
      #elif defined(HAVE_LONG_LONG)
      typedef unsigned long long      uint64;
      #define USE_INT64 1
      #elif SIZEOF_LONG == 8
      typedef unsigned long           uint64;
      #define USE_INT64 1
      #elif defined(UINT64_TYPE)
      typedef UINT64_TYPE             uint64;
      #define USE_INT64 1
      #endif
      
      

      et pour ocaml (j'ai pas trouvé de source en ligne ):

      #if SIZEOF_INT == 4
      typedef int int32;
      typedef unsigned int uint32;
      #define ARCH_INT32_PRINTF_FORMAT ""
      #elif SIZEOF_LONG == 4
      typedef long int32;
      typedef unsigned long uint32;
      #define ARCH_INT32_PRINTF_FORMAT "l"
      #elif SIZEOF_SHORT == 4
      typedef short int32;
      typedef unsigned short uint32;
      #define ARCH_INT32_PRINTF_FORMAT ""
      #else
      #error "No 32-bit integer type available"
      #endif
      
      #if defined(ARCH_INT64_TYPE)
      typedef ARCH_INT64_TYPE int64;
      typedef ARCH_UINT64_TYPE uint64;
      #else
      #  ifdef ARCH_BIG_ENDIAN
      typedef struct { uint32 h, l; } uint64, int64;
      #  else
      typedef struct { uint32 l, h; } uint64, int64;
      #  endif
      #endif
      
      

      Est-ce que ce genre d'incompatibilité arrive souvent ? Est-ce un bug ?

      • [^] # Re: Un problème de macro ?

        Posté par  . Évalué à 4.

        Non ce n'est pas un bug, les typedefs désignent bien deux choses différentes lorsque l'architecture n'est pas 64bits : un unsigned long long pour poker et une structure de deux membres pour OCaml. Il n'y a aucun espoir de pouvoir faire passer l'un pour l'autre et, justement, le compilateur l'interdit.

        Ce qui pourrait peut-être marcher c'est renommer une variante avec une macro du préprocesseur avant d'inclure un des entêtes (sans oublier de le désactiver juste après pour ne pas impacter les autres inclusions!) et ensuite utiliser le nouveau nom dans ton code. Par exemple en renommant l'alias d'OCaml :

        #define uint64 ocamluint64
        #define int64 ocamlint64
        #define uint32 ocamluint32
        #define int32 ocamlint32
        #include <caml/config.h>
        #include <caml/autreentête OCaml>
        #undef uint64
        #undef int64
        #undef uint32
        #undef int32
        
        #include <poker_defs.h>
        
        void ma_fonction_utilisant_le_type_ocaml(ocamluint64);
        
        

        Sans résultat garanti ;-)

Suivre le flux des commentaires

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