multiple définition de ImageMagick

Question

Lorsque vous essayez de compiler des versions plus récentes de ImageMagick (v6.8.7-2 ou plus tard, v6.8.7-1 est très bien), je reçois un tas de:

CCLD  magick/libMagickCore-6.Q16.la 
magick/.libs/magick_libMagickCore_6_Q16_la-animate.o: In function `__pthread_cleanup_routine': 
/usr/include/pthread.h:581: multiple definition of `__pthread_cleanup_routine' 
magick/.libs/magick_libMagickCore_6_Q16_la-accelerate.o:/usr/include/pthread.h:581: first defined here 
magick/.libs/magick_libMagickCore_6_Q16_la-annotate.o: In function `__pthread_cleanup_routine': 
/usr/include/pthread.h:581: multiple definition of `__pthread_cleanup_routine' 
magick/.libs/magick_libMagickCore_6_Q16_la-accelerate.o:/usr/include/pthread.h:581: first defined here 
magick/.libs/magick_libMagickCore_6_Q16_la-artifact.o: In function `__pthread_cleanup_routine': 
/usr/include/pthread.h:581: multiple definition of `__pthread_cleanup_routine' 
magick/.libs/magick_libMagickCore_6_Q16_la-accelerate.o:/usr/include/pthread.h:581: first defined here 
magick/.libs/magick_libMagickCore_6_Q16_la-attribute.o: In function `__pthread_cleanup_routine': 
/usr/include/pthread.h:581: multiple definition of `__pthread_cleanup_routine' 
magick/.libs/magick_libMagickCore_6_Q16_la-accelerate.o:/usr/include/pthread.h:581: first defined here 
... goes on for quite a bit longer, all the same. 

Le branche pertinente du /usr/include/pthread.h (de 2.5-118.el5_10.2-têtes glibc) est:

/* Function called to call the cleanup handler. As an extern inline 
function the compiler is free to decide inlining the change when 
needed or fall back on the copy which must exist somewhere else. */ 

extern __inline void 
__pthread_cleanup_routine (struct __pthread_cleanup_frame *__frame) 
{ 
    if (__frame->__do_it) // <======= this is :581 
    __frame->__cancel_routine (__frame->__cancel_arg); 
} 

J'ai poster sur le forum ImageMagick sans réponse.

Même si vous ne pouvez pas dire exactement ce qui se passe, comment puis-je commencer à déterminer si le problème est avec ImageMagick ou pthread.h? Où vais-je à partir de là? Grep pthread_cleanup_routine -r * affiche uniquement les correspondances avec les fichiers d'objets binaires - aucun code source d'ImageMagick ne contient pthread_cleanup_routine. Quelques-unes des sources incluent "pthread.h" bien sûr. Cela me porte à croire qu'il s'agit d'un problème de glibc, pas d'un problème ImageMagick ... mais, encore une fois, les versions précédentes d'ImageMagick se compilent très bien. (J'ai comparé les sources svn entre les versions où il s'est cassé.Il y a beaucoup de changements de configuration/makefile, mais rien ne me vient à l'esprit.)

Je suis sur CentOS 5, noyau 2.6 .18-308.24.1.el5, gcc v4.9.0, ld v2.24, en-têtes de glibc 2.5-118.el5_10.2

Answer 1

J'ai vu beaucoup de gens publier des problèmes similaires avec d'autres paquets qu'ImageMagick. J'espère que d'autres trouveront cela utile.

Changer pthread.h, juste avant __pthread_cleanup_routine:

extern __inline void 

à

if __STDC__VERSION__ < 199901L 
extern 
#endif 
__inline void 

résout le problème. Les anciennes versions de glibc avaient un problème quand -fexceptions était utilisé, et une conformité en ligne non-C99 (voir http://gcc.gnu.org/ml/gcc-patches/2006-11/msg01030.html). Des glibc plus récentes permettraient également de résoudre le problème, mais cela devrait être une solution temporaire pour ceux qui ne veulent/ne devraient pas ne le mettez pas à jour.

ImageMagick svn 13539 (qui deviendra plus tard v6.8.7-2) a commencé à utiliser -fexceptions.

Answer 2

Je fait face à cette erreur par un nouveau compilateur gcc (4.9.3)

Le script configure ImageMagick (6.8.9_7) vérifiait si le compilateur prend en charge la norme gnu99. Si oui, le script configure définit standard pour gnu99 et active également openmp.

La sémantique en ligne change avec la norme gnu99, ce qui provoque la définition multiple de la fonction en ligne externe https://gcc.gnu.org/onlinedocs/gcc-4.9.3/gcc/Inline.html#Inline. J'ai donc ajouté le flag -fgnu89-inline du compilateur pour utiliser une sémantique plus ancienne pour inline et il a corrigé le problème.