>On Sat, 13 Jul 2013 20:10:20 -0500 >Tyrin Price <[email protected]> wrote: > > I get the following error in my LFS-7.3 build during the make of > SDL-1.2.15 which says it builds on LFS-7.3 > > In file included from ./src/video/x11/SDL_x11dyn.c:96:0: > ./src/video/x11/SDL_x11sym.h:168:1: error: conflicting types for > '_XData32' In file included from ./src/video/x11/SDL_x11dyn.h:34:0, > from ./src/video/x11/SDL_x11dyn.c:26: > /usr/include/X11/Xlibint.h:595:12: note: previous declaration of > '_XData32' was here > make: *** [build/SDL_x11dyn.lo] Error 1 > > I am trying to build in a chroot environment on my main distribution > (Debian Wheezy). > > Is that what is causing the problem? DO I need to actually boot my > LFS for this one? > > -- > > -=[Ty]=- >
No... This appears to be a problem where two headers collide, trying to both define the same thing. I don't know if this is a issue known to others, so I'll just try to make myself usefull and write up what I find while digesting the issue. The collision appears to be between the X system headers and SDL headers. The SDL version you are using is the same one I am using (I have no problems). Xlibint.h is coming from libX11, and _XData32() has been in there since 2004, accoding to my copy of the git repository. This is getting interesting. From the header, I see that the macro LONG64 needs to be defined for the libX11's definition of _XData32() to go live. At the same time, that same definition in SDL_x11sym.h is also under the control of by the same macro. It also has the following comment: /* Not required...these only exist in code in headers on some 64-bit platforms, and are removed via macros elsewhere, so it's safe for them to be missing. */ So, from all this, it would seem that on your system, LONG64 gets defined, but on for example, my system it does not. Since LONG64 is not defined in sources of either package, you might want to first check the build log (you log the build, right?). See if there are some `-DLONG64' flags passed to the compiler. There are none in my logs. Maybe some have been added by `./configure'? If that fails, I guess you might as well try booting your system and trying it like that. Doesn't seem to me that there should be a reason your build fails when it passes for others. -- You don't need an AI for a robot uprising. Humans will do just fine.
signature.asc
Description: PGP signature
-- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
