This is the mail archive of the crossgcc@sources.redhat.com mailing list for the crossgcc project.
See the CrossGCC FAQ for lots more information.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
Yep, that's it. __i686 is indeed being defined to 1.
Here's a patch I apply to fix a similar problem with sparc;
this has been fixed in glibc mainline now, I think, but similar
problems might lurk.
http://kegel.com/crosstool/crosstool-0.28-rc36/patches/glibc-2.3.2/glibc-2.3.2-sparc32-sysdep.patch
Is there any reason why an equivalent patch (i.e. #undef __i686) in sysdeps/unix/sysv/linux/i386/sysdep.h wouldn't do the trick for me?
It probably would fix it. In fact, you can make it a one-liner: #undef __i686 That's always safe, I think.
Switching the -c to -E in the-gcc-command-that-failed produces no output.
You have to get rid of the -o foo.o, else the preprocessed output goes into the .o file!
Next steps? You might have noticed that this is right on the boundary of where I have a clue and where I don't!
Try making that one-line patch! If you haven't ever made a patch, see http://kegel.com/academy/opensource.html#patches - Dan
-- Trying to get a job as a c++ developer? See http://kegel.com/academy/getting-hired.html
------ Want more information? See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/ Want to unsubscribe? Send a note to crossgcc-unsubscribe@sources.redhat.com
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |