On Tue, 2012-11-13 at 16:42 -0700, Chris Larson wrote: > On Tue, Nov 13, 2012 at 6:59 AM, Richard Purdie > <richard.pur...@linuxfoundation.org> wrote: > Signed-off-by: Richard Purdie > <richard.pur...@linuxfoundation.org> > --- > diff --git > a/meta/recipes-extended/bash/bash-4.2/crossfix.patch > b/meta/recipes-extended/bash/bash-4.2/crossfix.patch > new file mode 100644 > index 0000000..f587c34 > --- a/dev/null > +++ b/meta/recipes-extended/bash/bash-4.2/crossfix.patch > @@ -0,0 +1,28 @@ > +Adding @CROSS_COMPILE@ to CFLAGS_FOR_BUILD causes errors > like: > + > +mkbuiltins.o: In function `open': > +/usr/include/x86_64-linux-gnu/bits/fcntl2.h:54: undefined > reference to `xopen' > +mkbuiltins.o: In function `read': > +/usr/include/x86_64-linux-gnu/bits/unistd.h:45: undefined > reference to `xread' > +collect2: ld returned 1 exit status > + > +when compiling on a 64 bit x86 build system for a 32 bit x86 > target since > +config.h confuses the compiler about settings. By removing > the option, config.h > +isn't used and the compiler stops getting confused. > + > +Upstream-Status: Pending > +RP 2012/11/13 > > Relying on the target config.h to build a host tool could fail if the > build and target environments differ greatly, which is likely why > mkbuiltins.c has hardcoded defines assuming less about the host (just > POSIX) based on the CROSS_COMPILE define. I don't think removing that > is the best fix, personally.
Agreed. I'd actually misread that file and thought that it was using config.h in the CROSS_COMPILE case. > The reason for this failure has to do with a particular set of > circumstances. A header in the bash source tree defines STRING() based > on HAVE_STRINGIZE. This define overwrites the unistd.h define of the > same macro. The unistd.h definitions of read() and open() wrap the > call to the real functions to implement FORTIFY_SOURCES, and those > wrappers use STRING() to do it. As a result, for any host that > defaults to -DFORTIFY_SOURCES, STRING() returns 'x' resulting in a > concatenation rather than an assembly level rename of the function > being called. > > If we add -DHAVE_STRINGIZE in the CROSS_COMPILE case, then STRING() > will be defined to something useful, and therefore the FORTIFY_SOURCES > wrappers don't get hosed. > > See http://git.yoctoproject.org/cgit/cgit.cgi/meta-mentor/commit/?id=da0ff91 > for an alternative fix which may be more likely to be accepted upstream. > This is better, yes. Is there a reason this is in meta-mentor and not OE-Core? I'd really like to pull it into OE-Core... Cheers, Richard _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core