> On Jan 14, 2016, at 1:22 PM, Phil Blundell <[email protected]> wrote: > > How does that patch help with this issue? It seems to be adding ifunc > support which isn't obviously related to the problem at hand.
Its not obvious but its related because now that ifunc support is available to gold, it marks ‘longjmp’ as STT_GNU_IFUNC and is able to add a runtime RELATIVE relocation for this symbol. > > p. > > On Thu, 2016-01-14 at 10:27 -0800, Khem Raj wrote: >> Carlos >> >> Can you try this fix >> >> https://github.com/kraj/openembedded-core/commit/0e35ad5a35262cfb7a6249ce158f76d1399d6cb4 >> >> >> This should help with this issue. >> >> >>> On Sep 14, 2015, at 4:01 PM, Carlos Alberto Lopez Perez <[email protected]> >>> wrote: >>> >>> On 14/09/15 09:24, Khem Raj wrote: >>>> >>>>> On Sep 11, 2015, at 7:51 AM, Phil Blundell <[email protected]> wrote: >>>>> >>>>> On Fri, 2015-09-11 at 14:49 +0200, Carlos Alberto Lopez Perez wrote: >>>>>> * When ld-is-gold is enabled in DISTRO_FEATURES, matchbox-keyboard >>>>>> will fail to build with this error: >>>>>> >>>>>> ld: error: matchbox-keyboard-image.o: requires unsupported dynamic >>>>>> reloc R_ARM_MOVW_ABS_NC; recompile with -fPIC >>>>> >>>>> This is only an issue for ARM (and only for Thumb2 at that). I don't >>>>> think it's necessarily appropriate to force -fPIC on all targets. >>>>> >>>>> Also, before adding this sort of hack it would be worth verifying >>>>> whether this is in fact a toolchain bug and, if it is, fixing it there. >>>>> >>>> >>>> This may not be a toolchain bug if there is a MOVW_ABS relocation being >>>> emitted >>>> into an object that is eventually linked into shared library. Using -fPIC >>>> seems to be right fix >>>> I know bfd linker silently ignored these relocations and generated bad .so >>>> files but that was fixed >>>> several years ago. So I think what needs to be looked at is why does same >>>> .o links ok with bfd linker >>>> is it some linker trampoline code thats in question here which may be >>>> different between gold and ld >>>> >>>> Carlos >>>> >>>> Can you check the linker cmdline of failing link step and see if its >>>> generating a shared object there ? >>>> if thats the case and I assume gcc is generating this relocation into both >>>> >>> >>> It looks is generating an executable (matchbox-keyboard). >>> >>> Full log: http://sprunge.us/VPIN >>> >> > >
signature.asc
Description: Message signed with OpenPGP using GPGMail
-- _______________________________________________ Openembedded-core mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-core
