| Message ID | 20190611103248.31917-1-nylon7@andestech.com |
|---|---|
| State | Not Applicable |
| Delegated to: | John Crispin |
| Headers | show |
| Series | None | expand |
On 2019-06-11 12:32, Nylon Chen wrote: > When a building package has -flto option leads to building error > > We must use the gcc-ar wrapper instead of ar to invoke ar with the right > plugin arguments for handling the LTO objects when -flto is specified. > > Signed-off-by: Che-Wei Chuang <cnoize@andestech.com> > Signed-off-by: Nylon Chen <nylon7@andestech.com> Why is this nds32 specific? Does it not make sense to extend this to all targets? - Felix
On Tue, Jun 11, 2019 at 11:21:45PM +0800, Felix Fietkau wrote: > On 2019-06-11 12:32, Nylon Chen wrote: > > When a building package has -flto option leads to building error > > > > We must use the gcc-ar wrapper instead of ar to invoke ar with the right > > plugin arguments for handling the LTO objects when -flto is specified. > > > > Signed-off-by: Che-Wei Chuang <cnoize@andestech.com> > > Signed-off-by: Nylon Chen <nylon7@andestech.com> > Why is this nds32 specific? Not only nds32 > Does it not make sense to extend this to all targets? I am not sure, but I am trying the others toolchain x86-gcc gcc version 7.4.0 (Ubuntu 7.4.0-1ubuntu1~18.04) cc -flto -c f1.c cc -flto -c f2.c ar -r f.a f1.o f2.o ar: creating f.a rm -rf *.o *.a gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.11) cc -flto -c f1.c cc -flto -c f2.c ar -r f.a f1.o f2.o ar: creating f.a ar: f1.o: plugin needed to handle lto object ar: f2.o: plugin needed to handle lto object rm -rf *.o *.a riscv riscv64-linux-gcc -flto -c f1.c riscv64-linux-gcc -flto -c f2.c riscv64-linux-ar -r f.a f1.o f2.o riscv64-linux-ar: creating f.a rm -rf *.o *.a nds32 nds32le-linux-gcc -flto -c f1.c nds32le-linux-gcc -flto -c f2.c nds32le-linux-ar -r f.a f1.o f2.o nds32le-linux-ar: creating f.a nds32le-linux-ar: f1.o: plugin needed to handle lto object nds32le-linux-ar: f2.o: plugin needed to handle lto object nds32le-linux-gcc-ar -r f.a f1.o f2.o nds32le-linux-glibc-v3-upstream/bin/../lib/gcc/nds32le-linux/8.0.1/../../../../nds32le-linux/bin/ar: creating f.a rm -rf *.o *.a arm arm-none-eabi-gcc -flto -c f1.c arm-none-eabi-gcc -flto -c f2.c arm-none-eabi-ar -r f.a f1.o f2.o arm-none-eabi-ar: creating f.a arm-none-eabi-ar: f1.o: plugin needed to handle lto object arm-none-eabi-ar: f2.o: plugin needed to handle lto object arm-none-eabi-gcc-ar -r f.a f1.o f2.o gcc-arm-none-eabi-8-2018-q4-major/bin/../lib/gcc/arm-none-eabi/8.2.1/../../../../arm-none-eabi/bin/ar: creating f.a rm -rf *.o *.a summary 1.the same issue could be found in other vendors' toolchain 2.pass on newer than x86-gcc5.4 version 3.specificed -ffat-lto-objects during building toolchain could be solved > > - Felix
diff --git a/rules.mk b/rules.mk index 80cb3d63f4..8d1c2b7cd2 100644 --- a/rules.mk +++ b/rules.mk @@ -256,9 +256,15 @@ ifeq ($(CONFIG_EXTERNAL_TOOLCHAIN),) TARGET_RANLIB:=$(TARGET_CROSS)gcc-ranlib TARGET_NM:=$(TARGET_CROSS)gcc-nm else - TARGET_AR:=$(TARGET_CROSS)ar - TARGET_RANLIB:=$(TARGET_CROSS)ranlib - TARGET_NM:=$(TARGET_CROSS)nm + ifeq ($(ARCH),nds32) + TARGET_AR:=$(TARGET_CROSS)gcc-ar + TARGET_RANLIB:=$(TARGET_CROSS)gcc-ranlib + TARGET_NM:=$(TARGET_CROSS)gcc-nm + else + TARGET_AR:=$(TARGET_CROSS)ar + TARGET_RANLIB:=$(TARGET_CROSS)ranlib + TARGET_NM:=$(TARGET_CROSS)nm + endif endif BUILD_KEY=$(TOPDIR)/key-build