Makefile: prevent libgcc to be linked twice
PATCH 1/1 Makefile: prevent libgcc to be linked twice
If we define USE_PRIVATE_LIBGCC, PLATFORM_LIBS is used during link. During this last link editing, libgcc may be listed twice and fail.
Prevent this using "filter-out" in top Makefile.
--- Makefile | 3 ++- 1 files changed, 2 insertions(+), 1 deletions(-)
Makefile +2 -1
@@ -311,7 +311,8 @@ endif else PLATFORM_LIBGCC = -L $(shell dirname `$(CC) $(CFLAGS) -print-libgcc-file-name`) -lgcc endif -PLATFORM_LIBS += $(PLATFORM_LIBGCC) +PLATFORM_LIBS := $(PLATFORM_LIBGCC) \ + $(filter-out %$(PLATFORM_LIBGCC), $(PLATFORM_LIBS)) export PLATFORM_LIBS # Special flags for CPP when processing the linker script.
Signature · 1 line
1.7.5.4
PATCH 1/1 Makefile: prevent libgcc to be linked twice
Quoted 4 lines · On Monday 17 October 2011 09:41:15 Nicolas Ferre wrote:
If we define
USE_PRIVATE_LIBGCC,PLATFORM_LIBSis used during link. During this last link editing, libgcc may be listed twice and fail.
Prevent this using "filter-out" in topMakefile.
could you please provide more details ? libgcc should not be listed twice. -mike
PATCH 1/1 Makefile: prevent libgcc to be linked twice
On 10/17/2011 07:25 PM, Mike Frysinger :
Quoted 7 lines · On Monday 17 October 2011 09:41:15 Nicolas Ferre wrote:
Quoted 4 lines
If we define
USE_PRIVATE_LIBGCC,PLATFORM_LIBSis used during link. During this last link editing, libgcc may be listed twice and fail.
Prevent this using "filter-out" in topMakefile.could you please provide more details ? libgcc should not be listed twice.
I compile current u-boot with the flowing command line:
make -j5 CROSS_COMPILE=arm-linux-gnueabi- USE_PRIVATE_LIBGCC=yes at91sam9m10g45ek_nandflash
On an Ubuntu 11.10 with Linaro's cross-toolchain (targeting ARMv7). My SoC is an ARM926 so I use the "USE_PRIVATE_LIBGCC=yes" switch. This will prevent the build to take libgcc from my host but compile the u-boot embedded libgcc: everything is fine, good feature.
But, here is the final link editing stage:
UNDEF_SYM=`arm-linux-gnueabi-objdump -x board/atmel/at91sam9m10g45ek/libat91sam9m10g45ek.o api/libapi.o arch/arm/cpu/arm926ejs/at91/libat91.o arch/arm/cpu/arm926ejs/libarm926ejs.o arch/arm/lib/libarm.o common/libcommon.o disk/libdisk.o drivers/bios_emulator/libatibiosemu.o drivers/block/libblock.o drivers/dma/libdma.o drivers/fpga/libfpga.o drivers/gpio/libgpio.o drivers/hwmon/libhwmon.o drivers/i2c/libi2c.o drivers/input/libinput.o drivers/misc/libmisc.o drivers/mmc/libmmc.o drivers/mtd/libmtd.o drivers/mtd/nand/libnand.o drivers/mtd/onenand/libonenand.o drivers/mtd/spi/libspi_flash.o drivers/mtd/ubi/libubi.o drivers/net/libnet.o drivers/net/phy/libphy.o drivers/pci/libpci.o drivers/pcmcia/libpcmcia.o drivers/power/libpower.o drivers/rtc/librtc.o drivers/serial/libserial.o drivers/spi/libspi.o drivers/twserial/libtws.o drivers/usb/eth/libusb_eth.o drivers/usb/gadget/libusb_gadget.o drivers/usb/host/libusb_host.o drivers/usb/musb/libusb_musb.o drivers/usb/phy/libusb_phy.o dri vers/video/libvideo.o drivers/watchdog/libwatchdog.o fs/cramfs/libcramfs.o fs/ext2/libext2fs.o fs/fat/libfat.o fs/fdos/libfdos.o fs/jffs2/libjffs2.o fs/reiserfs/libreiserfs.o fs/ubifs/libubifs.o fs/yaffs2/libyaffs2.o lib/libfdt/libfdt.o lib/libgeneric.o lib/lzma/liblzma.o lib/lzo/liblzo.o lib/zlib/libz.o net/libnet.o post/libpost.o | sed -n -e 's/.*\(__u_boot_cmd_.*\)/-u\1/p'|sort|uniq`; cd /home/nferre/workspace/u-boot/u-boot-git && arm-linux-gnueabi-ld -pie -T u-boot.lds -Bstatic -Ttext 0x73f00000 $UNDEF_SYM arch/arm/cpu/arm926ejs/start.o --start-group api/libapi.o arch/arm/cpu/arm926ejs/at91/libat91.o arch/arm/cpu/arm926ejs/libarm926ejs.o arch/arm/lib/libarm.o common/libcommon.o disk/libdisk.o drivers/bios_emulator/libatibiosemu.o drivers/block/libblock.o drivers/dma/libdma.o drivers/fpga/libfpga.o drivers/gpio/libgpio.o drivers/hwmon/libhwmon.o drivers/i2c/libi2c.o drivers/input/libinput.o drivers/misc/libmisc.o drivers/mmc/libmmc.o drivers/mtd/libmtd.o drivers/mtd/nand /libnand.o drivers/mtd/onenand/libonenand.o drivers/mtd/spi/libspi_flash.o drivers/mtd/ubi/libubi.o drivers/net/libnet.o drivers/net/phy/libphy.o drivers/pci/libpci.o drivers/pcmcia/libpcmcia.o drivers/power/libpower.o drivers/rtc/librtc.o drivers/serial/libserial.o drivers/spi/libspi.o drivers/twserial/libtws.o drivers/usb/eth/libusb_eth.o drivers/usb/gadget/libusb_gadget.o drivers/usb/host/libusb_host.o drivers/usb/musb/libusb_musb.o drivers/usb/phy/libusb_phy.o drivers/video/libvideo.o drivers/watchdog/libwatchdog.o fs/cramfs/libcramfs.o fs/ext2/libext2fs.o fs/fat/libfat.o fs/fdos/libfdos.o fs/jffs2/libjffs2.o fs/reiserfs/libreiserfs.o fs/ubifs/libubifs.o fs/yaffs2/libyaffs2.o lib/libfdt/libfdt.o lib/libgeneric.o lib/lzma/liblzma.o lib/lzo/liblzo.o lib/zlib/libz.o net/libnet.o post/libpost.o board/atmel/at91sam9m10g45ek/libat91sam9m10g45ek.o --end-group /home/nferre/workspace/u-boot/u-boot-git/arch/arm/lib/eabi_compat.o /home/nferre/workspace/u-boot/u-boot-git/arch/arm/lib /libgcc.o /home/nferre/workspace/u-boot/u-boot-git/arch/arm/lib/libgcc.o -Map u-boot.map -o u-boot
And you see that there is arch/arm/lib/libgcc.o included twice in object files that have to be linked together. I think that it is coming from the PLATFORM_LIBS variable so I modified like in my patch which solves the problem.
Best regards,
Signature · 1 line
Nicolas Ferre
PATCH 1/1 Makefile: prevent libgcc to be linked twice
Quoted 7 lines · On Tuesday 18 October 2011 04:30:27 Nicolas Ferre wrote:
On 10/17/2011 07:25 PM, Mike Frysinger :
Quoted 6 lines · On Monday 17 October 2011 09:41:15 Nicolas Ferre wrote:
Quoted 4 lines
If we define
USE_PRIVATE_LIBGCC,PLATFORM_LIBSis used during link. During this last link editing, libgcc may be listed twice and fail.
Prevent this using "filter-out" in topMakefile.
Quoted 6 lines
Quoted 2 lines
could you please provide more details ? libgcc should not be listed twice.
I compile current u-boot with the flowing command line:
make -j5 CROSS_COMPILE=arm-linux-gnueabi- USE_PRIVATE_LIBGCC=yesat91sam9m10g45ek_nandflash
the issue shows up when using the board shortcut, and only when your tree is already configured. if you use at91sam9m10g45ek_nandflash_config and then another make, it works fine. if you start from a clean tree (git clean -x -d), it works fine.
this is due to PLATFORM_LIBS appending PLATFORM_LIBGCC when the tree has been configured, then exporting PLATFORM_LIBS, then the board shortcut running $(MAKE). the exported PLATFORM_LIBS gets LIBGCC appended a second time.
this issue will show up with any value that gets appended to PLATFORM_LIBS and not just libgcc. the arm code already hits this and deals with it locally. seems like we should instead unify this logic, or redo PLATFORM_LIBS so that it isn't an issue in the first place.
-mike
PATCH 1/1 Makefile: prevent libgcc to be linked twice
On 10/18/2011 06:06 PM, Mike Frysinger :
Quoted 11 lines · On Tuesday 18 October 2011 04:30:27 Nicolas Ferre wrote:
Quoted 10 lines
On 10/17/2011 07:25 PM, Mike Frysinger :
Quoted 8 lines · On Monday 17 October 2011 09:41:15 Nicolas Ferre wrote:
Quoted 4 lines
If we define
USE_PRIVATE_LIBGCC,PLATFORM_LIBSis used during link. During this last link editing, libgcc may be listed twice and fail.
Prevent this using "filter-out" in topMakefile.could you please provide more details ? libgcc should not be listed twice.
Quoted 8 lines
Quoted 3 lines
I compile current u-boot with the flowing command line:
make -j5 CROSS_COMPILE=arm-linux-gnueabi- USE_PRIVATE_LIBGCC=yesat91sam9m10g45ek_nandflashthe issue shows up when using the board shortcut, and only when your tree is already configured. if you use
at91sam9m10g45ek_nandflash_configand then another make, it works fine. if you start from a clean tree (git clean -x -d), it works fine.
Ah thanks for the information. Indeed it is a more common way of using the configuration/compilation flow...
Quoted 8 lines
this is due to
PLATFORM_LIBSappendingPLATFORM_LIBGCCwhen the tree has been configured, then exportingPLATFORM_LIBS, then the board shortcut running $(MAKE). the exportedPLATFORM_LIBSgets LIBGCC appended a second time.this issue will show up with any value that gets appended to
PLATFORM_LIBSand not just libgcc. the arm code already hits this and deals with it locally. seems like we should instead unify this logic, or redoPLATFORM_LIBSso that it isn't an issue in the first place.
Yes, that it a bit confusing... But with proper explanation, we can deal with this.
Thanks for your help, best regards,
Signature · 1 line
Nicolas Ferre