[yocto] Solved : Re: Problems building U-Boot for x86_64
Ferry Toth
ftoth at telfort.nl
Sat Jan 27 13:45:16 PST 2018
Op donderdag 30 november 2017 09:03:46 CET schreef Stefan Roese:
> Hi Ferry,
>
> On 08.10.2017 18:50, Ferry Toth wrote:
> > Op Fri, 25 Aug 2017 22:30:42 +0000, schreef Ferry Toth:
> >
> >> Op Fri, 25 Aug 2017 21:22:40 +0200, schreef Ferry Toth:
> >>
> >>> Khem Raj wrote:
> >>>
> >>>
> >>>
> >>>>
> >>>> On 8/23/17 3:40 PM, Ferry Toth wrote:
> >>>>> Op Wed, 23 Aug 2017 14:51:55 -0700, schreef Khem Raj:
> >>>>>
> >>>>>> On 8/23/17 2:29 PM, Ferry Toth wrote:
> >>>>>>> Ferry Toth wrote:
> >>>>>>>
> >>>>>>>> Khem Raj wrote:
> >>>>>>>>
> >>>>>>>>> On 8/22/17 11:41 PM, Ferry Toth wrote:
> >>>>>>>>>> I am having trouble building a specific U-Boot version with
> >>>>>>>>>> Yocto. Outside of Yocto on 64 bit Ubuntu 17.04 with multilib it
> >>>>>>>>>> builds fine.
> >>>>>>>>>>
> >>>>>>>>>> I am extending meta-intel-edison to build a 64 bit Poke Morty,
> >>>>>>>>>> with a vanilla 64-bit kernel (4.12). This is working quite well.
> >>>>>>>>>>
> >>>>>>>>>> My host is x86_64, the target is core2 with tune=core-64.
> >>>>>>>>>>
> >>>>>>>>>> Without 64bit tune I can build U-Boot fine. With 64bit it can
> >>>>>>>>>> not link, appearently because it needs lbgcc.a
> >>>>>>>>>
> >>>>>>>>> what is exact error message ? is it while compiling host bits or
> >>>>>>>>> target bits ?
> >>>>>>>>
> >>>>>>>> The failing line is:
> >>>>>>>> x86_64-poky-linux-ld.bfd -Bsymbolic -Bsymbolic-functions -m
> >>>>>>>> elf_i386 --emit- relocs --wrap=__divdi3 --wrap=__udivdi3
> >>>>>>>> --wrap=__moddi3 --wrap=__umoddi3 -- gc-sections -pie -Bstatic
> >>>>>>>> --no-dynamic-linker -Ttext 0x01101000 -o u-boot -T u-boot.lds
> >>>>>>>> arch/x86/cpu/start.o --start-group arch/x86/cpu/built-in.o
> >>>>>>>> arch/x86/lib/built-in.o board/intel/edison/built-in.o
> >>>>>>>> cmd/built-in.o common/built-in.o disk/built-in.o
> >>>>>>>> drivers/built-in.o drivers/dma/built-in.o drivers/gpio/built-in.o
> >>>>>>>> drivers/i2c/built-in.o drivers/mmc/built-in.o
> >>>>>>>> drivers/mtd/built-in.o drivers/mtd/onenand/built-in.o
> >>>>>>>> drivers/mtd/spi/built- in.o drivers/net/built-in.o
> >>>>>>>> drivers/net/phy/built-in.o drivers/pci/built- in.o
> >>>>>>>> drivers/power/built-in.o drivers/power/battery/built-in.o
> >>>>>>>> drivers/power/domain/built-in.o
> >>>>>>>> drivers/power/fuel_gauge/built-in.o drivers/power/mfd/built-in.o
> >>>>>>>> drivers/power/pmic/built-in.o drivers/power/regulator/built-in.o
> >>>>>>>> drivers/serial/built-in.o drivers/spi/built-in.o
> >>>>>>>> drivers/usb/common/built-in.o drivers/usb/dwc3/built- in.o
> >>>>>>>> drivers/usb/emul/built-in.o drivers/usb/eth/built-in.o
> >>>>>>>> drivers/usb/gadget/built-in.o drivers/usb/gadget/udc/built-in.o
> >>>>>>>> drivers/usb/host/built-in.o drivers/usb/musb-new/built-in.o
> >>>>>>>> drivers/usb/musb/built-in.o drivers/usb/phy/built-in.o
> >>>>>>>> drivers/usb/ulpi/built-in.o dts/built-in.o fs/built-in.o
> >>>>>>>> lib/built-in.o net/built-in.o test/built-in.o test/dm/built-in.o
> >>>>>>>> --end-group arch/x86/lib/lib.a -Map u-boot.map ERROR: oe_runmake
> >>>>>>>> failed arch/x86/lib/built-in.o: In function `__wrap___udivdi3':
> >>>>>>>> /home/ferry/tmp/edison-intel/my/edison-
> >>>>>>>> morty/out/linux64/build/tmp/work/edison-poky-linux/u-boot/edison-
> >>>>> v2017.03-
> >>>>>>>> r0/git/arch/x86/lib/gcc.c:25: undefined reference to
> >>>>>>>> `__normal___udivdi3'
> >>>>>>>
> >>>>>>> I as believe the missing lib is libgcc.a I just my sysroot and
> >>>>>>> found it here:
> >>>>>>
> >>>>>> the linker cmdline above does not link with libgcc and there might
> >>>>>> be a good reason for that, many standalone applications dont link
> >>>>>> with libgcc intentionally. You could look into the code and see if
> >>>>>> it can be written differently such that gcc does not have to invoke
> >>>>>> a helper function from gcc runtime. Another option is to link with
> >>>>>> libgcc explicitly
> >>>>>
> >>>>> If change my setup to build for a 32bit target, it build u-boot
> >>>>> without error.
> >>>>
> >>>> compiler may not be generating calls for the missing function.
> >>>>
> >>>>> When I build the same git outside yocto on 64bit with multilib
> >>>>> installed it also builds without error. In that case the make command
> >>>>> would be: make -j8 edison_defconfig
> >>>>
> >>>> same is possible. Can you do readelf -sW gcc.o and see if there is a
> >>>> undefined reference to __normal___udivdi3
> >>>
> >>> 20: 00000000 22 FUNC GLOBAL HIDDEN 4 __wrap___divdi3 21:
> >>> 00000000 0 NOTYPE GLOBAL DEFAULT UND __normal___divdi3 22:
> >>> 00000000 22 FUNC GLOBAL HIDDEN 6 __wrap___udivdi3 23:
> >>> 00000000 0 NOTYPE GLOBAL DEFAULT UND __normal___udivdi3 24:
> >>> 00000000 22 FUNC GLOBAL HIDDEN 8 __wrap___moddi3 25:
> >>> 00000000 0 NOTYPE GLOBAL DEFAULT UND __normal___moddi3 26:
> >>> 00000000 22 FUNC GLOBAL HIDDEN 10 __wrap___umoddi3 27:
> >>> 00000000 0 NOTYPE GLOBAL DEFAULT UND __normal___umoddi3
> >>
> >> AFAIKT when building for a 32-bit target is only that U-Boot makefile is
> >> called with CROSS_COMPILE=i686-poky-linux- CC=i686-poky-linux-gcc
> >> instead of CROSS_COMPILE=x86_64-poky-linux- CC=x86_64-poky-linux-gcc.
> >>
> >> Result from readelf -sW gcc.o built wuth i686:
> >>
> >> 20: 00000000 27 FUNC GLOBAL HIDDEN 4 __wrap___divdi3 21:
> >> 00000000 0 NOTYPE GLOBAL DEFAULT UND __normal___divdi3 22:
> >> 00000000 27 FUNC GLOBAL HIDDEN 6 __wrap___udivdi3 23: 00000000
> >> 0 NOTYPE GLOBAL DEFAULT UND __normal___udivdi3 24: 00000000 27
> >> FUNC GLOBAL HIDDEN 8 __wrap___moddi3 25: 00000000 0 NOTYPE
> >> GLOBAL DEFAULT UND __normal___moddi3 26: 00000000 27 FUNC GLOBAL
> >> HIDDEN 10 __wrap___umoddi3 27: 00000000 0 NOTYPE GLOBAL DEFAULT
> >> UND __normal___umoddi3
> >>
> >> The path to libs and incs is the same (x86_64...) and I can't find any
> >> libgcc.a there. Still it links in this case.
> >>
> >> Maybe in the 64-bit case I need to add i686-poky-linux-gcc to native and
> >> modify the recipe to use that?
> >>
> >>
> >>>>> My conclusion: I have some bb variable set to the wrong value or I
> >>>>> need to get multilib installed into /..../sysroots/x86_64-linux/lib.
> >>>>>
> >>>>> So how to do that?
> >>>>>
> >>>>>>> sysroots/lib32-edison/usr/lib/i686-pokymllib32-linux/6.2.0/
> >>>>>>> sysroots/lib32-edison-tcbootstrap/usr/lib/i686-pokymllib32-
> >> linux/6.2.0/
> >>>>>>> sysroots/edison/usr/lib64/x86_64-poky-linux/6.2.0/
> >>>>>>> sysroots/edison-tcbootstrap/usr/lib64/x86_64-poky-linux/6.2.0/
> >>>>>>>
> >>>>>>> How compile log shows:
> >>>>>>> NOTE: make -j8 CROSS_COMPILE=x86_64-poky-linux-
> >>>>>>> CC=x86_64-poky-linux-gcc --sysroot=/..../sysroots/edison V=1
> >>>>>>> HOSTCC=gcc -isystem/..../sysroots/x86_64-linux/usr/include -O2
> >>>>>>> -pipe -L/..../sysroots/x86_64-linux/usr/lib
> >>>>>>> -L/..../sysroots/x86_64-linux/lib
> >>>>>>> -Wl,-rpath-link,/..../sysroots/x86_64-linux/usr/lib
> >>>>>>> -Wl,-rpath-link,/..../sysroots/x86_64-linux/lib
> >>>>>>> -Wl,-rpath,/..../sysroots/x86_64-linux/usr/lib
> >>>>>>> -Wl,-rpath,/..../sysroots/x86_64-linux/lib -Wl,-O1 -C
> >>>>>>> /..../out/linux64/build/tmp/work/edison-poky-linux/u-boot/edison-
> >>>>>>> v2017.03-r0/git
> >>>>>>> O=/..../out/linux64/build/tmp/work/edison-poky-linux/u-
> >>>>>>> boot/edison-v2017.03-r0/build edison_defconfig
> >>>>>>>
> >>>>>>> (.... my edits to shorten the uninteresting part of the path)
> >>>>>>>
> >>>>>>> I would think: --sysroot points to /edison dir which actually
> >>>>>>> contains libgcc.a, but -i, _l and -W1 options point to host dirs
> >>>>>>> that don't have the lib.
> >>>>>>>
> >>>>>>>
> >>>>>>>>>> I attempted to add multilib, but although that immediately
> >>>>>>>>>> exposed bugs in other recipes but actually adds libgcc.a, it
> >>>>>>>>>> does that for the target sysroot only.
> >>>>>>>>>>
> >>>>>>>>>> And for some reason, U-Boot is built with the native gcc
> >>>>>>>>>> (x86_64-linux),
> >>>>>>>>>> and multilib does not add libgcc.a to that sysroot.
> >>>>>>>>>>
> >>>>>>>>>> So, how do I add multilib to -native sysroot, preferably only to
> >>>>>>>>>> -native and not to the target, as the target has not further use
> >>>>>>>>>> for it?
> >>>>>>>>>>
> >>>>>>>>>> Strangest thing is in u-boot.inc there is:
> >>>>>>>>>> EXTRA_OEMAKE = 'CROSS_COMPILE=${TARGET_PREFIX}
> >>>>>>>>>> CC="${TARGET_PREFIX}gcc ${TOOLCHAIN_OPTIONS}" V=1'
> >>>>>>>>>> EXTRA_OEMAKE += 'HOSTCC="${BUILD_CC} ${BUILD_CFLAGS}
> >>>>>>>>>> ${BUILD_LDFLAGS}"'
> >>>>>>>>>>
> >>>>>>>>>> But when I check my log file:
> >>>>>>>>>> NOTE: make -j8 CROSS_COMPILE=x86_64-poky-linux-
> >>>>>>>>>> CC=x86_64-poky-linux- gcc ......
> >>>>>>>>>>
> >>>>>>>>>> So TARGET_PREFIX resolves to x86_64-poky-linux, but I think my
> >>>>>>>>>> target is core2_64 (or something like that). Is that normal for
> >>>>>>>>>> U-Boot?
> >>>>>>>>>
> >>>>>>>>> thats ok.
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>> I am a little lost, so any help would be greatly appreciated
> >
> > I added multilib to the meta0intel-edison-bsp machine conf:
> > #multilib
> > require conf/multilib.conf
> > MULTILIBS = "multilib:lib32"
> > DEFAULTTUNE_virtclass-multilib-lib32 = "core2-32"
> > IMAGE_INSTALL_append = " lib32-libgcc"
> >
> > This exposes a lot recipy bugs in other places that needed to be fixed
> > first.
> >
> > Then I changed IMAGE_INSTALL += "u-boot" to "lib32_u-boot". Now it builds
> > without error.
> >
> > Now I changed IMAGE_INSTALL tot EXTRA_IMAGEDEPENDS. I believe that will
> > prevent u-boot and the otherwise unecessary multilib to be installed on
> > the image. Not sure if that really works out as I hope.
> >
> > All of this now causes populate_sdk to fail, but I will post that
> > seperately.
> >
> > Thanks all for the usefull comments.
>
> Just a quick update on this. I recently sent a patch to the U-Boot list,
> fixing this x86 toolchain dependency in mainline U-Boot:
>
> https://patchwork.ozlabs.org/patch/842613/
>
> This patch will be included in the upcoming release (2018.01).
And it is working brilliantly regardless if I set DEFAULTTUNE = “core2-64” or not, thanks so much!
--
Ferry Toth
> Thanks,
> Stefan
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20180127/32683956/attachment.html>
More information about the yocto
mailing list