Make: -nostartfiles -nodefaultlibs are not flags of LD but flags of GCC #3836

AlexanderVasiljev · 2021-06-03T07:07:23Z

Summary

The flags -nostartfiles -nodefaultlibs are not the flags of LD but are the flags of GCC. It will cause errors on new GNU ld 2.36.x.
Now GNU ld just doesn't recognize them.
New GNU ld version 2.36.x will treat this as error.
See issue #3826

This patch will use GCC as LD. So the main change is

-LD = $(CROSSDEV)ld
+LD = $(CROSSDEV)gcc

This PR covers arm, avr, z80, or1k, misos, hc. All boards in the repository of these archs are corrected to be linked with GCC. At least they are compilable.

Impact

GCC will be used in linkage stage, so every LD flag should be prefixed with -Wl.
Every board should correct linker flags.

The common change for most boards is

-NXFLATLDFLAGS1 = -r -d -warn-common
-NXFLATLDFLAGS2 = $(NXFLATLDFLAGS1) -T$(TOPDIR)/binfmt/libnxflat/gnu-nxflat-pcrel.ld -no-check-sections
+NXFLATLDFLAGS1 = -r -Wl,-d -Wl,-warn-common
+NXFLATLDFLAGS2 = $(NXFLATLDFLAGS1) -T$(TOPDIR)/binfmt/libnxflat/gnu-nxflat-pcrel.ld -Wl,-no-check-sections

Testing

custom board

Ouss4

Shouldn't we also add these flags to CXXFLAGS?

gustavonihei · 2021-06-03T10:08:28Z

I believe adding those flags to CFLAGS is not the right option, since CFLAGS (and CXXFLAGS) relate to Compile flags.
-nostarfiles and -nodefaultlibs are Link Options according to GCC documentation: https://gcc.gnu.org/onlinedocs/gcc/Link-Options.html

I believe that we should keep them as LDFLAGS and change the Linker command to call the GCC frontend (LD = $(CROSSDEV)gcc).
This change will also be needed for supporting LTO builds, eventually.

xiaoxiang781216

Agree with @gustavonihei, it's better to change LD to ${CROSSDEV}/gcc

xiaoxiang781216 · 2021-06-03T10:43:53Z

As @gustavonihei suggest that the right fix is change LD to xxx-gcc.

AlexanderVasiljev · 2021-06-03T11:00:49Z

It is not so simple.

LD: nuttx
arm-none-eabi-gcc: error: unrecognized command line option '--start-group'
arm-none-eabi-gcc: error: unrecognized command line option '--end-group'

gustavonihei · 2021-06-03T11:04:35Z

It is not so simple.

LD: nuttx
arm-none-eabi-gcc: error: unrecognized command line option '--start-group'
arm-none-eabi-gcc: error: unrecognized command line option '--end-group'

Yeah, these flags and some others are specific to LD, so when provided to the GCC frontend they must be provided with -Wl,--start-group

gustavonihei · 2021-06-03T11:11:35Z

It is not so simple.
LD: nuttx
arm-none-eabi-gcc: error: unrecognized command line option '--start-group'
arm-none-eabi-gcc: error: unrecognized command line option '--end-group'
Yeah, these flags and some others are specific to LD, so when provided to the GCC frontend they must be provided with -Wl,--start-group

Other changes that I have locally here for a previous attempt to enable the LTO build:

-LDSTARTGROUP ?= --start-group
-LDENDGROUP ?= --end-group
+LDSTARTGROUP ?= -Wl,--start-group
+LDENDGROUP ?= -Wl,--end-group
 LDFLAGS += $(ARCHSCRIPT)
 
 BOARDMAKE = $(if $(wildcard board$(DELIM)Makefile),y,)
@@ -103,7 +103,7 @@ board/libboard$(LIBEXT):
 
 nuttx$(EXEEXT): $(STARTUP_OBJS) board/libboard$(LIBEXT)
        @echo "LD: nuttx"
-       $(Q) $(LD) --entry=__start $(LDFLAGS) $(LIBPATHS) $(EXTRA_LIBPATHS) \
+       $(Q) $(LD) -Wl,--entry=__start $(LDFLAGS) $(LIBPATHS) $(EXTRA_LIBPATHS) \
                -o $(NUTTX) $(STARTUP_OBJS) $(EXTRA_OBJS) \
                $(LDSTARTGROUP) $(LDLIBS) $(EXTRA_LIBS) $(LDENDGROUP)
 ifneq ($(CONFIG_WINDOWS_NATIVE),y)

 ifeq ($(CONFIG_CYGWIN_WINTOOL),y)
-  LDFLAGS += -Map="${shell cygpath -w $(TOPDIR)/nuttx.map}" --cref
+  LDFLAGS += -Wl,-Map="${shell cygpath -w $(TOPDIR)/nuttx.map}" -Wl,--cref
 else
-  LDFLAGS += -Map=$(TOPDIR)/nuttx.map --cref
+  LDFLAGS += -Wl,-Map=$(TOPDIR)/nuttx.map -Wl,--cref
 endif
 
 ifeq ($(CONFIG_DEBUG_SYMBOLS),y)

AlexanderVasiljev · 2021-06-03T11:17:21Z

@gustavonihei you are right. But grep for LDFLAGS!

gustavonihei · 2021-06-03T11:35:15Z

@gustavonihei you are right. But grep for LDFLAGS!

You do not need to change every flag provided to LDFLAGS. These ones I mentioned are the ones that are specific to the LD linker. There might be some others that may need to passed via -Wl,, but the majority are handled via the GCC frontend, e.g. -L and -l.

davids5 · 2021-06-03T12:50:24Z

Do we have any idea how the linker was interpreting these and what the effect was?

AlexanderVasiljev · 2021-06-03T12:53:48Z

@davids5 , please, see issue #3826 and my question on binutlis https://sourceware.org/pipermail/binutils/2021-June/116825.html
Linker just ignored these flags

davids5 · 2021-06-03T13:20:42Z

@AlexanderVasiljev @Ouss4 - I will test this today.

davids5 · 2021-06-03T13:22:33Z

@v01d - any implication on the Cmake side?

gustavonihei

The correct approach is described in comment #3836 (comment)

davids5 · 2021-06-03T13:28:53Z

@gustavonihei -On a separate note for a future feature with LTO it would be great to get it working,

I have seen it destroy working code when we needed the size saving. I did not dig into it as the time, nor do I want to have to just because of an NuttX upgrade. So please consider Kconfig control (with it off by default)

davids5 · 2021-06-03T13:32:04Z

@AlexanderVasiljev - we should either close this or update it to invoke the compiler - how would you like to proceed?

protobits · 2021-06-03T13:33:34Z

@v01d - any implication on the Cmake side?

Not really, cmake is much clearer about the distinction between compiler/linker flags so I did not encounter this issue.

gustavonihei · 2021-06-03T13:34:07Z

@gustavonihei -On a separate note for a future feature with LTO it would be great to get it working,

I have seen it destroy working code when we needed the size saving. I did not dig into it as the time, nor do I want to have to just because of an NuttX upgrade. So please consider Kconfig control (with it off by default)

Yes, I have done a quick attempt at enabling the LTO build for ESP32, and I haven't assessed what exactly had been removed, but that's how far I've got.

davids5 · 2021-06-03T13:36:35Z

@gustavonihei -On a separate note for a future feature with LTO it would be great to get it working,
I have seen it destroy working code when we needed the size saving. I did not dig into it as the time, nor do I want to have to just because of an NuttX upgrade. So please consider Kconfig control (with it off by default)

Yes, I have done a quick attempt at enabling the LTO build for ESP32, and I haven't assessed what exactly had been removed, but that's how far I've got.

So far LTO has not proven to be Link Time Optimization but rather Limited Time Off :)

AlexanderVasiljev · 2021-06-03T13:39:56Z

@davids5 @gustavonihei OK, I will try to change LD for GCC in this pull request.

protobits · 2021-06-03T13:42:06Z

@v01d - any implication on the Cmake side?

Not really, cmake is much clearer about the distinction between compiler/linker flags so I did not encounter this issue.

A related comment could be that in fact CMake does not normally access ld directly (it uses the compiler to link). This means that I had to account for the -Wl and other issues arising from this difference.

AlexanderVasiljev · 2021-06-03T13:46:19Z

I will start with armv7-m.

AlexanderVasiljev · 2021-06-03T14:27:30Z

Linker specific flags are used intensively in NXFLATLDFLAGS1 and NXFLATLDFLAGS2 macros. But I cannot find where they
are used and how to test them.

xiaoxiang781216 · 2021-06-04T15:26:43Z

let's sqush all patch into one.

masayuki2009 · 2021-06-10T11:38:47Z

@masayuki2009 What is your config name?

sim:smp

AlexanderVasiljev · 2021-06-10T11:41:27Z

@masayuki2009 It have built successfully on my PC. Can you make clean? And reconfigure! Make.defs file should be relocated!

CC:  sim_appinit.c
CC:  sim_bringup.c
AR (create): libboard.a   dummy.o sim_appinit.o sim_bringup.o 
make[2]: Leaving directory '/home/avasiljev/dv/spectran/remkomplekt/embedded/mainBoard/tmpflags/incubator-nuttx/boards/sim/sim/sim/src'
LD:  nuttx
make[1]: Leaving directory '/home/avasiljev/dv/spectran/remkomplekt/embedded/mainBoard/tmpflags/incubator-nuttx/arch/sim/src'

masayuki2009 · 2021-06-10T11:45:12Z

@masayuki2009 It have built successfully on my PC. Can you make clean?

CC:  sim_appinit.c
CC:  sim_bringup.c
AR (create): libboard.a   dummy.o sim_appinit.o sim_bringup.o 
make[2]: Leaving directory '/home/avasiljev/dv/spectran/remkomplekt/embedded/mainBoard/tmpflags/incubator-nuttx/boards/sim/sim/sim/src'
LD:  nuttx
make[1]: Leaving directory '/home/avasiljev/dv/spectran/remkomplekt/embedded/mainBoard/tmpflags/incubator-nuttx/arch/sim/src'

Yes. I tried git clean -fdx for both directories before rebuilding the target.
Can you try make V=1 -j7

AlexanderVasiljev · 2021-06-10T11:52:58Z

@masayuki2009 Here are my steps
git clone https://github.com/apache/incubator-nuttx.git
tools/configure.sh sim:smp
make V=1 -j7

Result

make[2]: Leaving directory '/tmp/nuttx/incubator-nuttx/boards/sim/sim/sim/src'
echo "LD:  nuttx"
LD:  nuttx
gcc -r  -L"/tmp/nuttx/incubator-nuttx/staging" -L board  -o nuttx.rel up_head.o up_smpsignal.o -Wl,--start-group -lsched -ldrivers -lboards -lc -lmm -larch -lapps -lfs -lbinfmt -lboard  -Wl,--end-group
objcopy --redefine-syms=nuttx-names.dat nuttx.rel
cc -g -Wl,-verbose 2>&1 | \
     sed -e '/====/,/====/!d;//d' -e 's/__executable_start/_stext/g' -e 's/__init_array_start/_sinit/g' \
         -e 's/__init_array_end/_einit/g' -e 's/__fini_array_start/_sfini/g' -e 's/__fini_array_end/_efini/g' >nuttx.ld
echo "__init_array_start = .; __init_array_end = .; __fini_array_start = .; __fini_array_end = .;" >>nuttx.ld
"cc" -g -L board -T nuttx.ld -o /tmp/nuttx/incubator-nuttx/nuttx nuttx.rel up_hostirq.o up_hostmemory.o up_hosttime.o up_simuart.o up_testset.o up_simsmp.o -lpthread -lrt
nm /tmp/nuttx/incubator-nuttx/nuttx | \
        grep -v '\(compiled\)\|\(\.o$\)\|\( [aUw] \)\|\(\.\.ng$\)\|\(LASH[RL]DI\)' | \
        sort > /tmp/nuttx/incubator-nuttx/System.map
make[1]: Leaving directory '/tmp/nuttx/incubator-nuttx/arch/sim/src'
if [ -w /tftpboot ] ; then \
        cp -f nuttx /tftpboot/nuttx.sim; \
fi
echo nuttx > nuttx.manifest
printf "%s\n" *.map >> nuttx.manifest

AlexanderVasiljev · 2021-06-10T12:11:36Z

@masayuki2009 Is your apps on the recent commit?

AlexanderVasiljev · 2021-06-10T12:33:45Z

@masayuki2009 I remember that I encountered this error with -lgcc_s. It was when I tried to migrate ld to gcc for x86. It failed because of "-static" flag, which was intoduced by this commit

aed9bcc#diff-2d60830f249881b0f33a243863a1f9fa2194e57d21faa126a49cd8e8c0f31c5b

I gave up to migrate x86. Could you explain why -static is needed there?

Doesn't your toolchain have -static flag by default?

masayuki2009 · 2021-06-10T13:10:07Z

I gave up to migrate x86. Could you explain why -static is needed there?

@AlexanderVasiljev
When I added the change, I had link errors with gcc on my Ubuntu 18.04 x86_64.
However, I've just confirmed that there is no error without -static option.

Doesn't your toolchain have -static flag by default?

How can I confirm it?
My gcc shows

$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/7/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 7.5.0-3ubuntu1~18.04' --with-bugurl=file:///usr/share/doc/gcc-7/README.Bugs --enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr --with-gcc-major-version-only --program-suffix=-7 --program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie --with-system-zlib --with-target-system-zlib --enable-objc-gc=auto --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-offload-targets=nvptx-none --without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 7.5.0 (Ubuntu 7.5.0-3ubuntu1~18.04)

lulingar · 2021-06-10T13:37:16Z

boards/sim/sim/sim/scripts/Make.defs

@@ -83,7 +83,7 @@ endif
 CC = $(CROSSDEV)cc
 CXX = $(CROSSDEV)c++
 CPP = $(CROSSDEV)cc -E -P -x c
-LD = $(CROSSDEV)ld
+LD = $(CROSSDEV)gcc


This is breaking our clang-based build. Our build fails like:

echo "LD: nuttx" LD: nuttx gcc -r -L"/nuttx/staging" -L board -o nuttx.rel up_head.o -Wl,--start-group -lsched -ldrivers -lboards -lc -lmm -larch -lapps -lnet -lfs -lbinfmt -lboard -Wl,--end-group /bin/sh: 1: gcc: not found make[1]: Leaving directory '/nuttx/arch/sim/src' make[1]: *** [Makefile:314: nuttx] Error 127 make: *** [tools/Makefile.unix:422: nuttx] Error 2 The command '/bin/sh -c bear -v make -j $(grep -c ^processor /proc/cpuinfo) V=2' returned a non-zero code: 2 make: *** [process/Build.mk:39: builder] Error

Previously it was:

ld -r -L"/nuttx/staging" -L board -o nuttx.rel up_head.o --start-group -lsched -ldrivers -lboards -lc -lmm -larch -lapps -lnet -lfs -lbinfmt -lboard --end-group

Certainly I agree with the suggestion this change should have been widely advertised before merging.

diff --git a/boards/sim/sim/sim/scripts/Make.defs b/boards/sim/sim/sim/scripts/Make.defs index 65600e15ec..e4615f12f1 100644 --- a/boards/sim/sim/sim/scripts/Make.defs +++ b/boards/sim/sim/sim/scripts/Make.defs @@ -83,7 +83,7 @@ endif CC = $(CROSSDEV)cc CXX = $(CROSSDEV)c++ CPP = $(CROSSDEV)cc -E -P -x c -LD = $(CROSSDEV)gcc +LD = $(CROSSDEV)cc ifeq ($(CONFIG_HOST_MACOS),y) STRIP = $(CROSSDEV)strip AR = $(TOPDIR)/tools/macar-rcs.sh

@lulingar Please, try applying this patch

Thanks, it failed further down the build, like:

echo "LD: nuttx" LD: nuttx cc -r -L"/nuttx/staging" -L board -o nuttx.rel up_head.o --start-group -lsched -ldrivers -lboards -lc -lmm -larch -lapps -lnet -lfs -lbinfmt -lboard --end-group clang: error: unsupported option '--start-group' clang: error: unsupported option '--end-group' make[1]: Leaving directory '/nuttx/arch/sim/src' make[1]: *** [Makefile:314: nuttx] Error 1 make: *** [tools/Makefile.unix:422: nuttx] Error 2

But it seems #3904 fixes this, I'm testing it out.

It didn't fix it, in our clang-only build we don't have gcc. I'm testing some other ways to go about this. But this begs the question, why forcing this way the compiler to be gcc?

@lulingar Do you have any instructions how to config clang build? What OS do you use?

In my Ubuntu 21.04 machine, I've just successfully built sim:nsh with clang. For forcing the clang compiler since it's not symlinked to cc, I've applied the following patch:

diff --git a/boards/sim/sim/sim/scripts/Make.defs b/boards/sim/sim/sim/scripts/Make.defs index 067914aea2..0d2a861890 100644 --- a/boards/sim/sim/sim/scripts/Make.defs +++ b/boards/sim/sim/sim/scripts/Make.defs @@ -80,10 +80,10 @@ ifeq ($(CONFIG_SIM_M32),y) ARCHCPUFLAGSXX += -m32 endif -CC = $(CROSSDEV)cc -CXX = $(CROSSDEV)c++ -CPP = $(CROSSDEV)cc -E -P -x c -LD = $(CROSSDEV)gcc +CC = $(CROSSDEV)clang +CXX = $(CROSSDEV)clang++ +CPP = $(CROSSDEV)clang -E -P -x c +LD = $(CROSSDEV)clang ifeq ($(CONFIG_HOST_MACOS),y) STRIP = $(CROSSDEV)strip AR = $(TOPDIR)/tools/macar-rcs.sh

Also, I've successfully built sim:nsh on macOS with clang as the default compiler.

@lulingar, from the command line you've posted we can see that --start-group was incorrectly passed instead of -Wl,--start-group. Have you performed a distclean after you pulled the latest changes from upstream? Since the Makefiles from the board were changed, these are not automatically refreshed by make because the NuttX build system makes a copy of them on the ./tools/configure.sh step.

Thank you for the indications. I have tested aliasing clang as gcc, after the merge of #3904, and it worked.

@lulingar, I've opened #3921 for fixing the support for building the simulator on systems with Clang as the default compiler.

AlexanderVasiljev · 2021-06-10T14:55:00Z

@masayuki2009 I have just installed Ubuntu 18.04. I can see the same error. I will investigate it.

juniskane · 2021-06-10T15:00:30Z

arch/arm/src/Makefile

@@ -93,8 +93,8 @@ LDFLAGS += $(ARCHSCRIPT) $(EXTRALINKCMDS)

 # Override in Make.defs if linker is not 'ld'


Now misleading comment

Actually this comment still applies, since the GCC driver will call LD to perform the linking process.

hartmannathan · 2021-06-10T22:15:22Z

@xiaoxiang781216 , @davids5 , @AlexanderVasiljev

This change is now described in the CWIKI Release Notes for the (future) 10.2 release:

https://cwiki.apache.org/confluence/display/NUTTX/NuttX+10.2#ld-now-called-through-gcc

Please proofread and feel free to make corrections.

As this is a breaking change that happens when the Package Manager updates Binutils to 2.36.x, maybe it should be added to the website for anyone who encounters this problem pre-10.2-release?

hartmannathan · 2021-06-10T22:29:47Z

By the way, in places like this:

NXFLATLDFLAGS1 = -r -Wl,-d -Wl,-warn-common

Why does the -r option need to remain without -Wl,?

yamt · 2021-06-10T23:07:49Z

why do we need -nostartfiles -nodefaultlibs at all?
my understanding is that these options controls how cc generates ld command line arguments.
i don't see how it matters while we use ld directly.

besides, having cc as LD is very confusing.

gustavonihei · 2021-06-10T23:21:31Z

By the way, in places like this:
NXFLATLDFLAGS1 = -r -Wl,-d -Wl,-warn-common
Why does the -r option need to remain without -Wl,?

-r is a link option processed by the GCC driver, so it needs to be forwarded to the linker:

https://gcc.gnu.org/onlinedocs/gcc/Link-Options.html#:~:text=produce%20a%20relocatable%20object%20as%20output.%20this%20is%20also%20known%20as%20partial%20linking.

AlexanderVasiljev · 2021-06-11T07:49:37Z

By the way, in places like this:
NXFLATLDFLAGS1 = -r -Wl,-d -Wl,-warn-common
Why does the -r option need to remain without -Wl,?
-r is a link option processed by the GCC driver, so it needs to be forwarded to the linker:

https://gcc.gnu.org/onlinedocs/gcc/Link-Options.html#:~:text=produce%20a%20relocatable%20object%20as%20output.%20this%20is%20also%20known%20as%20partial%20linking.

GCC treat -r the same way as LD.
https://gcc.gnu.org/onlinedocs/gcc/Link-Options.html

-r

    Produce a relocatable object as output. This is also known as partial linking.

AlexanderVasiljev · 2021-06-11T08:04:12Z

why do we need -nostartfiles -nodefaultlibs at all?
my understanding is that these options controls how cc generates ld command line arguments.
i don't see how it matters while we use ld directly.

besides, having cc as LD is very confusing.

Almost every board configuration has these options. It seems like to be a copypasta. But actualy LD doesn't process them. My first proposal was to change it to CFLAGS. But changing LD to GCC can give more options for linking optimization. So it was decided to take more effort.

AlexanderVasiljev · 2021-06-11T08:42:35Z

@masayuki2009 Please, try this patch

boards/sim/sim/sim/scripts/Make.defs

@@ -197,5 +197,7 @@ ifeq ($(CONFIG_SIM_SANITIZE),y)
   HOSTLDFLAGS += -fsanitize=address -fsanitize=undefined -fno-omit-frame-pointer
 endif
 
 HOSTCFLAGS = $(ARCHWARNINGS) $(ARCHOPTIMIZATION) \
    $(ARCHCPUFLAGS) $(HOSTINCLUDES) $(EXTRAFLAGS) -pipe
+
+LDLINKFLAGS += -nostartfiles -nodefaultlibs

masayuki2009 · 2021-06-11T10:31:02Z

@masayuki2009 Please, try this patch

@AlexanderVasiljev
Thanks! The patch works with Ubuntu 18.04 x86_64.

yamt · 2021-06-14T03:07:26Z

why do we need -nostartfiles -nodefaultlibs at all?
my understanding is that these options controls how cc generates ld command line arguments.
i don't see how it matters while we use ld directly.
besides, having cc as LD is very confusing.

Almost every board configuration has these options. It seems like to be a copypasta. But actualy LD doesn't process them. My first proposal was to change it to CFLAGS. But changing LD to GCC can give more options for linking optimization. So it was decided to take more effort.

i'm not sure if i agree the decision. i submitted a revert. #3900

…of GCC It seems that those flags have always been gcc flags, and not ld flags. After decades of tolerating this, binutils 2.36.x no longer tolerates those flags but prints an error: arm-none-eabi-ld: Error: unable to disambiguate: -nostartfiles (did you mean --nostartfiles ?) See also apache/nuttx#3826 and the related apache/nuttx#3836 how this was solved in another project - I adopted that solution here 1:1 Change-Id: Id199e4d03d5aae07a347c98f47791f42c12008c6

AlexanderVasiljev mentioned this pull request Jun 3, 2021

arm-none-eabi-ld: Error: unable to disambiguate: -nostartfiles #3826

Closed

Ouss4 requested review from Ouss4, davids5 and xiaoxiang781216 June 3, 2021 08:47

Ouss4 reviewed Jun 3, 2021

View reviewed changes

Ouss4 linked an issue Jun 3, 2021 that may be closed by this pull request

arm-none-eabi-ld: Error: unable to disambiguate: -nostartfiles #3826

Closed

xiaoxiang781216 reviewed Jun 3, 2021

View reviewed changes

gustavonihei requested changes Jun 3, 2021

View reviewed changes

AlexanderVasiljev force-pushed the flags branch from 2832bc0 to 7642f53 Compare June 4, 2021 11:58

lulingar reviewed Jun 10, 2021

View reviewed changes

juniskane reviewed Jun 10, 2021

View reviewed changes

hartmannathan mentioned this pull request Jun 10, 2021

Unable to build for NUCLEO-L432KC under Arch Linux using ARM GNU toolchain in package repository #3209

Closed

AlexanderVasiljev mentioned this pull request Jun 11, 2021

boards/sim/sim/sim: correct LDLINKFLAGS after migrating from ld to gcc #3904

Merged

gustavonihei mentioned this pull request Jun 14, 2021

sim: Use cc as linker, which usually aliases to either GCC or Clang #3921

Merged

hartmannathan mentioned this pull request Jun 16, 2021

Revert "Make: use gcc as LD" #3900

Merged

xiaoxiang781216 mentioned this pull request Sep 6, 2021

Revert "arch: Replace ar and nm with gcc-ar and gcc-nm" #4477

Merged

Ouss4 mentioned this pull request Sep 10, 2021

nucleo-g431kb build error #4510

Closed

Ouss4 added this to To-Add in Release Notes - 10.2 Oct 11, 2021

jerpelea moved this from To-Add to Minor in Release Notes - 10.2 Oct 13, 2021

xiaoxiang781216 mentioned this pull request Jan 26, 2022

arch/Toolchain.defs: Simplify addition builtin library to EXTRA_LIBS #5332

Merged

rm5248 mentioned this pull request Aug 7, 2022

Use GCC for LD on MIPS processors #6800

Closed

		@@ -93,8 +93,8 @@ LDFLAGS += $(ARCHSCRIPT) $(EXTRALINKCMDS)

		# Override in Make.defs if linker is not 'ld'

Make: -nostartfiles -nodefaultlibs are not flags of LD but flags of GCC #3836

Make: -nostartfiles -nodefaultlibs are not flags of LD but flags of GCC #3836

Conversation

AlexanderVasiljev commented Jun 3, 2021 • edited

Summary

Impact

Testing

Ouss4 left a comment

Choose a reason for hiding this comment

gustavonihei commented Jun 3, 2021 • edited

xiaoxiang781216 left a comment

Choose a reason for hiding this comment

xiaoxiang781216 commented Jun 3, 2021

AlexanderVasiljev commented Jun 3, 2021

gustavonihei commented Jun 3, 2021 • edited

gustavonihei commented Jun 3, 2021

AlexanderVasiljev commented Jun 3, 2021

gustavonihei commented Jun 3, 2021

davids5 commented Jun 3, 2021 • edited

AlexanderVasiljev commented Jun 3, 2021

davids5 commented Jun 3, 2021

davids5 commented Jun 3, 2021

gustavonihei left a comment

Choose a reason for hiding this comment

davids5 commented Jun 3, 2021

davids5 commented Jun 3, 2021

protobits commented Jun 3, 2021

gustavonihei commented Jun 3, 2021

davids5 commented Jun 3, 2021

AlexanderVasiljev commented Jun 3, 2021

protobits commented Jun 3, 2021

AlexanderVasiljev commented Jun 3, 2021

AlexanderVasiljev commented Jun 3, 2021

xiaoxiang781216 commented Jun 4, 2021

masayuki2009 commented Jun 10, 2021

AlexanderVasiljev commented Jun 10, 2021 • edited

masayuki2009 commented Jun 10, 2021

AlexanderVasiljev commented Jun 10, 2021

AlexanderVasiljev commented Jun 10, 2021

AlexanderVasiljev commented Jun 10, 2021

masayuki2009 commented Jun 10, 2021

lulingar Jun 10, 2021 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

gustavonihei Jun 11, 2021 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

AlexanderVasiljev commented Jun 10, 2021

Choose a reason for hiding this comment

Choose a reason for hiding this comment

hartmannathan commented Jun 10, 2021

hartmannathan commented Jun 10, 2021

yamt commented Jun 10, 2021

gustavonihei commented Jun 10, 2021 • edited

AlexanderVasiljev commented Jun 11, 2021

AlexanderVasiljev commented Jun 11, 2021

AlexanderVasiljev commented Jun 11, 2021

masayuki2009 commented Jun 11, 2021

yamt commented Jun 14, 2021

AlexanderVasiljev commented Jun 3, 2021 •

edited

gustavonihei commented Jun 3, 2021 •

edited

gustavonihei commented Jun 3, 2021 •

edited

davids5 commented Jun 3, 2021 •

edited

AlexanderVasiljev commented Jun 10, 2021 •

edited

lulingar Jun 10, 2021 •

edited

gustavonihei Jun 11, 2021 •

edited

gustavonihei commented Jun 10, 2021 •

edited