Summary: | media-libs/devil-1.7.8 fails to build with media-libs/libjpeg-turbo-1.1.90: il_bmp.c:(.text+0x70): multiple definition of `ilFloatToHalfOverflow' | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Piotr Szymaniak <bugzie> |
Component: | [OLD] Games | Assignee: | Gentoo Games <games> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | anarchy, dcommander, graphics+disabled, skunk, ssuominen, tetromino |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
Build.log
This one seems to work for me. |
Description
Piotr Szymaniak
2012-01-07 13:42:48 UTC
Created attachment 298227 [details]
Build.log
PS Someone got the same issue already on forums.g.o. → http://forums.gentoo.org/viewtopic-p-6922340.html Well, as said on the forum, this seems to be "the package fails to build with >=gcc:4.3". If that's the case, '-fgnu89-inline' might be a valid workaround. Given when that one was released/stabilized, it should give you a hint about the status of media-libs/devil. I tried "CFLAGS="-O2 -pipe -march=native -fgnu89-inline" emerge -a1v devil" and it failed as well. There seems to be something odd here - I've just tested the lib and it builds just fine on x86 with same libtool/gcc/binutils/glibc as in the original report (OK, no autoreconf, so libtool doesn't mater, but the rest stands). I confirm the bug is reproducible with a flag + jpeg. Sorry for bad English. Hi. I wrote that post on the forum. Removing jpeg flag indeed lets devIL compile without bug but render it useless for me. (In reply to comment #7) > Hi. I wrote that post on the forum. Removing jpeg flag indeed lets devIL > compile without bug but render it useless for me. What useflags did you you built devil with ? It may or may not matter, but which package virtual/jpeg does resolves to (it's media-libs/jpeg-8c here) ? (In reply to comment #8) > It may or may not matter, but which package virtual/jpeg does resolves to? For me it's media-libs/libjpeg-turbo (In reply to comment #8) > (In reply to comment #7) > > Hi. I wrote that post on the forum. Removing jpeg flag indeed lets devIL > > compile without bug but render it useless for me. > > What useflags did you you built devil with ? > It may or may not matter, but which package virtual/jpeg does resolves to (it's > media-libs/jpeg-8c here) ? Hello. These are my flags for devil. It compiles with -jpeg. [ebuild R ] media-libs/devil-1.7.8 USE="X gif mng opengl png sdl tiff xpm -allegro -jpeg -lcms -openexr -static-libs" 0 kB Library used is also media-libs/libjpeg-turbo. media-libs/devil-1.7.8 with USE="X gif jpeg lcms mng opengl png sdl tiff -allegro -openexr -static-libs -xpm" builds with media-libs/libjpeg-turbo-1.1.1, but fails as described by other reporters with media-libs/libjpeg-turbo-1.1.90. I can build it with USE="jpeg" using the following: CFLAGS="-DNOINLINE" emerge -av devil Still trying to figure out where the conflict is though (In reply to comment #12) > I can build it with USE="jpeg" using the following: > > CFLAGS="-DNOINLINE" emerge -av devil > > Still trying to figure out where the conflict is though I think I may see the reason: does CFLAGS="-DINLINE=inline" work too ? (In reply to comment #13) > does CFLAGS="-DINLINE=inline" work too ? No. CFLAGS="-DNOINLINE" works, but CFLAGS="-DINLINE=inline" fails with .libs/libIL_la-il_doom.o: In function `iSwapUShort': il_doom.c:(.text+0x0): multiple definition of `iSwapUShort' .libs/libIL_la-il_alloc.o:il_alloc.c:(.text+0x0): first defined here .libs/libIL_la-il_doom.o: In function `iSwapShort': il_doom.c:(.text+0x2f): multiple definition of `iSwapShort' .libs/libIL_la-il_alloc.o:il_alloc.c:(.text+0x2f): first defined here .libs/libIL_la-il_doom.o: In function `iSwapUInt': il_doom.c:(.text+0x49): multiple definition of `iSwapUInt' .libs/libIL_la-il_alloc.o:il_alloc.c:(.text+0x49): first defined here .libs/libIL_la-il_doom.o: In function `iSwapInt': il_doom.c:(.text+0x8f): multiple definition of `iSwapInt' .libs/libIL_la-il_alloc.o:il_alloc.c:(.text+0x8f): first defined here [...] .libs/libIL_la-il_mp3.o: In function `SaveBigInt': il_mp3.c:(.text+0x5a1): multiple definition of `SaveBigInt' .libs/libIL_la-il_alloc.o:il_alloc.c:(.text+0x5a1): first defined here .libs/libIL_la-il_mp3.o: In function `SaveBigFloat': il_mp3.c:(.text+0x5d7): multiple definition of `SaveBigFloat' .libs/libIL_la-il_alloc.o:il_alloc.c:(.text+0x5d7): first defined here .libs/libIL_la-il_mp3.o: In function `SaveBigDouble': il_mp3.c:(.text+0x60f): multiple definition of `SaveBigDouble' .libs/libIL_la-il_alloc.o:il_alloc.c:(.text+0x60f): first defined here collect2: ld returned 1 exit status I reported this to the libjpeg-turbo upstream since this is fine with libjpeg-turbo-1.1.1, jpeg-6b, jpeg-8b, jpeg-8c but not with libjpeg-turbo-1.1.90 here: sf.net project libjpeg-turbo, Ticket, 3479995, "DevIl (openil) 1.7.8 fails to build with jpeg-turbo-1.1.90" https://sourceforge.net/tracker/?group_id=303195&atid=1278158 https://sourceforge.net/tracker/?func=detail&aid=3479995&group_id=303195&atid=1278158 Hi, guys. The error you're seeing doesn't seem to have anything to do with libjpeg-turbo, i.e. those aren't our symbols that are being multiply defined. Thus, I have no clue as to why libjpeg-turbo 1.1.90 would make any difference vs. 1.1.1. The libjpeg API has not changed since 1.1.1. Most of the functional changes in the 1.2 release have to do with the higher-level TurboJPEG API. All of the other changes since 1.1.1 should be "behind the scenes." Well, my idea was that it's an inherited flaw: in devil-1.7.8/include/IL/devil_internal_exports.h there's: #ifndef INLINE #if defined(__GNUC__) #define INLINE extern inline #elif defined(_MSC_VER) #define NOINLINE #define INLINE __inline #else #define INLINE inline #endif #endif jpeg-turbo defines INLINE too (a flaw inherited from jpeg config.h abuse). Comment 14 seems to suggest that I might have a point, but my guess at a solution is wrong. (In reply to comment #17) > Well, my idea was that it's an inherited flaw: > in devil-1.7.8/include/IL/devil_internal_exports.h there's: [ .. ] > jpeg-turbo defines INLINE too (a flaw inherited from jpeg config.h abuse). > Comment 14 seems to suggest that I might have a point, but my guess at a > solution is wrong. I came up with that -DNOINLINE from src-IL/include/il_manip.h, line 28, to skip the entire block of code where these are defined. (In reply to comment #16) > Hi, guys. The error you're seeing doesn't seem to have anything to do with > libjpeg-turbo, i.e. those aren't our symbols that are being multiply defined. > Thus, I have no clue as to why libjpeg-turbo 1.1.90 would make any difference > vs. 1.1.1. The libjpeg API has not changed since 1.1.1. Most of the > functional changes in the 1.2 release have to do with the higher-level > TurboJPEG API. All of the other changes since 1.1.1 should be "behind the > scenes." I didn't mean to sound like we are blaming libjpeg-turbo, but fact is that DevIl is /accidentally/ inheriting something from libjpeg-turbo, that is new in version 1.1.90 which will result in this error which at first doesn't look jpeg related at all. I was hoping you could take a look :-) Created attachment 299961 [details, diff]
This one seems to work for me.
(In reply to comment #17) > jpeg-turbo defines INLINE too (a flaw inherited from jpeg config.h abuse). > Comment 14 seems to suggest that I might have a point, but my guess at a > solution is wrong. You're right. This was added because, in 1.2, we inline the C color conversion routines for improved performance on non-SIMD platforms. Since the INLINE macro is used only internally to libjpeg-turbo, I think it's probably a bug that it is defined in jconfig.h. It probably should just be defined in config.h. Should now be fixed in libjpeg-turbo trunk. (In reply to comment #21) > Should now be fixed in libjpeg-turbo trunk. awesome, I tried to make a svn diff based on r731 between r739 (iirc) from libjpeg-turbo trunk to get a patch for the issue but it pulled a lot of unrelated changes too what would you recommend, pulling a snapshot from trunk and call it 1.1.90_p20120127 or is there any chance of rolling a 1.1.91 for the issue? The unrelated changes you're referring to are the addition of alpha-channel-specific colorspace constants, which are necessary to fix another Gentoo-reported bug: https://bugs.gentoo.org/show_bug.cgi?id=393471 There won't be a 1.1.91. 1.2.0 is ready to go, pending resolution of the above issue and this one. (In reply to comment #23) > There won't be a 1.1.91. OK no problem > 1.2.0 is ready to go, pending resolution of the above issue and this one. awesome meanwhile I've committed 1.1.90_p20120128 to resolve this bug, closing Thanks everyone |