On Thu, 2014-08-14 at 04:15 -0500, Peter A. Bigot wrote: > What this means is that the libraries built by gcc-runtime use > TARGET_CC_ARCH settings that don't necessarily match the target > compiler's defaults, and that ABI conflicts can result by linking in > those libraries when the non-default settings were absent in non-OE > application builds. ABI can only be "guaranteed" if every one of the > -mFOO=BAR passed in TARGET_CC_ARCH (*or defaulted by the compiler*) has > a corresponding -with-FOO=BAR option passed to (*or inferred by*) gcc's > configure. > > That's a pretty strong assumption to make. > > It may be that this can be worked around for the specific case I raised > by explicitly adding --with-arch=armv7-a to gcc-target's EXTRA_OECONF. I > do have to wonder whether the same should be done for any of armv7 > armv7-m armv7-r armv7e-m armv7ve armv8-a armv8-a+crc which are other > -march options that are armv6+, and whether there are other ABI issues > that might be hiding now or in the future because TARGET_CC_ARCH makes > more assumptions than gcc-target does. > > The solution I propose is to rework gcc-runtime's override of CC/CXX/CPP > so the libraries are built the same way they would be if they had been > built during gcc-target. > > From initial attempts this won't be easy to do. I'd be happy to keep > trying if this worries other people, but if I'm being too picky I'll > just suck it up and move on.
Its a valid concern, I just don't think anyone else has run into the kinds of issues you're seeing :/. We don't want to diverge too far from upstream gcc, equally, we need a working compiler... Cheers, Richard -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core