All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ferry Toth <ftoth@telfort.nl>
To: yocto@yoctoproject.org
Subject: Solved : Re: Problems building U-Boot for x86_64
Date: Sun, 8 Oct 2017 16:50:31 +0000 (UTC)	[thread overview]
Message-ID: <ordl0n$kh6$1@blaine.gmane.org> (raw)
In-Reply-To: onq8ei$suh$1@blaine.gmane.org

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.

>>>>>>>>> Ferry
>>>>>>>>>
>>>>>>>>>
>>>>>>>> --
>>>>>>>
>>>>>>>
>>>>>>> --
>>>> 
>>>> 
>>> --




  reply	other threads:[~2017-10-08 17:06 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-08-23  6:41 Problems building U-Boot for x86_64 Ferry Toth
2017-08-23 18:51 ` Khem Raj
2017-08-23 20:11   ` Ferry Toth
2017-08-23 21:29     ` Ferry Toth
2017-08-23 21:51       ` Khem Raj
2017-08-23 22:40         ` Ferry Toth
2017-08-24  4:07           ` Khem Raj
2017-08-24  6:51             ` Ferry Toth
2017-08-24 10:40               ` Stefano Babic
2017-08-24 13:09                 ` Ferry Toth
2017-08-24 15:48                   ` Stefano Babic
2017-08-24 16:35                     ` Ferry Toth
2017-08-24 21:34                       ` Ferry Toth
2017-08-25  8:18                         ` Ferry Toth
2017-08-25 19:22             ` Ferry Toth
2017-08-25 22:30               ` Ferry Toth
2017-10-08 16:50                 ` Ferry Toth [this message]
2017-11-30  8:03                   ` Solved : " Stefan Roese
2018-01-27 21:45                     ` Ferry Toth

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='ordl0n$kh6$1@blaine.gmane.org' \
    --to=ftoth@telfort.nl \
    --cc=yocto@yoctoproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.