Mbed-os: Issue in exporting sample to GCC (ARM Embedded) toolchain on mbed online compiler

[TomoYamanaka]

Description

• Type: Bug
• Priority: Major

---

Bug

As shown below, it seems that '-include mbed_config.h' is specified for g++ compiler
option only when exporting a program to GCC ARM Embedded on mbed online compiler.

CC_FLAGS = $(CPU) -c -g -fno-common -fmessage-length=0 -Wall -Wextra -Wno-unused-parameter -Wno-missing-field-initializers
CC_FLAGS += -fno-exceptions -fno-builtin -ffunction-sections -fdata-sections -fno-delete-null-pointer-checks -fomit-frame-pointer
CC_FLAGS += -MMD -MP


CPPC_FLAGS = -c -Wall -Wextra -Wno-unused-parameter -Wno-missing-field-initializers -fmessage-length=0 -fno-exceptions 
*snip* -DDEVICE_SPISLAVE=1 -DDEVICE_ANALOGIN=1 -DDEVICE_PWMOUT=1 -include mbed_config.h -MMD -MP

We think -include mbed_config.h should be needed not only for CPPC_FLAGS, but also for both CC_FLAGS and CPPC_FLAGS.
Otherwise, a compilation error should occur.

Please note that the issue might not occur if mbed export command is used for export.

Could you give us your opinion about the above?

[0xc0170]

cc @theotherjimmy

[theotherjimmy]

@TomoYamanaka That's a good point. That's why the tools already export a the exact commands that would be used to compile when run throught mbed-cli. If you export a project in the online compiler to GCC (ARM Embedded) you will see:

C_FLAGS += -include
C_FLAGS += mbed_config.h

#[snip]
CXX_FLAGS += -include
CXX_FLAGS += mbed_config.h

Which is what you are asking for, I think.

[TomoYamanaka]

@theotherjimmy

It was confirmed that at present, mbed_config.h specified as the include file for both gcc and g++ though I’m not sure when it was updated.

However, we faced another issue.
If we try to build the program using Makefile, we face the following error:

c:/program files (x86)/gnu tools arm embedded/4.9 2015q3/bin/../lib/gcc/arm-none-eabi/4.9.3/../../../../arm-none-eabi/lib/armv7-ar/thumb/fpu\libc.a(lib_a-fflush.o): In function `__sflush_r':
fflush.c:(.text.__sflush_r+0x7e): undefined reference to `__wrap__free_r'
c:/program files (x86)/gnu tools arm embedded/4.9 2015q3/bin/../lib/gcc/arm-none-eabi/4.9.3/../../../../arm-none-eabi/lib/armv7-ar/thumb/fpu\libc.a(lib_a-fclose.o): In function `_fclose_r':
fclose.c:(.text._fclose_r+0x4a): undefined reference to `__wrap__free_r'
fclose.c:(.text._fclose_r+0x58): undefined reference to `__wrap__free_r'
fclose.c:(.text._fclose_r+0x7a): undefined reference to `__wrap__free_r'
c:/program files (x86)/gnu tools arm embedded/4.9 2015q3/bin/../lib/gcc/arm-none-eabi/4.9.3/../../../../arm-none-eabi/lib/armv7-ar/thumb/fpu\libc.a(lib_a-svfprintf.o): In function `_svfprintf_r':
vfprintf.c:(.text._svfprintf_r+0x11e4): undefined reference to `__wrap__malloc_r'
c:/program files (x86)/gnu tools arm embedded/4.9 2015q3/bin/../lib/gcc/arm-none-eabi/4.9.3/../../../../arm-none-eabi/lib/armv7-ar/thumb/fpu\libc.a(lib_a-mprec.o): In function `_Balloc':
mprec.c:(.text._Balloc+0x24): undefined reference to `__wrap__calloc_r'
mprec.c:(.text._Balloc+0x40): undefined reference to `__wrap__calloc_r'
c:/program files (x86)/gnu tools arm embedded/4.9 2015q3/bin/../lib/gcc/arm-none-eabi/4.9.3/../../../../arm-none-eabi/lib/armv7-ar/thumb/fpu\libc.a(lib_a-svfiprintf.o): In function `__ssprint_r':
vfprintf.c:(.text.__ssprint_r+0x60): undefined reference to `__wrap__malloc_r'
vfprintf.c:(.text.__ssprint_r+0xc8): undefined reference to `__wrap__realloc_r'
vfprintf.c:(.text.__ssprint_r+0xd6): undefined reference to `__wrap__free_r'
collect2.exe: error: ld returned 1 exit status

In Makefile generated by online compiler, the following linker option is specified:
'-Wl,--wrap,_malloc_r' '-Wl,--wrap,_free_r' '-Wl,--wrap,_realloc_r' '-Wl,--wrap,_calloc_r'

and _malloc_r' '-Wl,--wrap,_free_r' '-Wl,--wrap,_realloc_r' '-Wl,--wrap,_calloc_r' is declared in mbed_alloc_wrappers.cpp only, so the above error occurs.
It seems that mbed-dev should be imported instead of mbed in order to build the program without changing the option. Or the above option is removed, the program should be built successfully.

Could you give us your opinion about the above?

[theotherjimmy]

What exactly are you exporting @TomoYamanaka ?

[theotherjimmy]

I think this is related to https://github.com/ARMmbed/mbed-os/issues/3728

[Osamu-Nakamura]

@theotherjimmy
We imported mbed_blinky with updating all the libraries, then exported it to GCC (ARM Embedded).

[TomoYamanaka]

@theotherjimmy

How about the status of this issue?

[bomilkar]

exact same issue here.
Would also like to know how to resolve this.

[theotherjimmy]

I think this is just the flags being out of date. I can reproduce this issue. I'm going to see if I can solve it.

[bomilkar]

Which flags do you think are out of date?
It looks to me as if there are references in libc.a which cannot be resolved. Something seem to be missing.

[bomilkar]

Update:

I changed the Makefile as follows:
remove this from LD: '-Wl,--wrap,_malloc_r' '-Wl,--wrap,_free_r' '-Wl,--wrap,_realloc_r' '-Wl,--wrap,_calloc_r'
remove this from LD_FLAGS: -Wl,--wrap,_malloc_r -Wl,--wrap,_free_r -Wl,--wrap,_realloc_r -Wl,--wrap,_calloc_r

With these 2 changes it woks for several projects.

[SuburbanDSP]

I just did a test export tonight to Nucleo-STM32L476RG. I found similar issues as Tomo Yamanaka. Fwiw project has mixed C and C++.

I removed the linker flags similarly to bomilkar, but with more functions wrapped, including exit() and atexit() from LD_FLAGS and it built perfectly, haven't executed yet.

btw, this machine is Ubuntu 14.04.4 LTS and
arm-none-eabi-gcc --version
arm-none-eabi-gcc (GNU Tools for ARM Embedded Processors) 4.9.3 20150529 (release) [ARM/embedded-4_9-branch revision 227977]
Copyright (C) 2014 Free Software Foundation, Inc.

[0xc0170]

I think this is just the flags being out of date. I can reproduce this issue. I'm going to see if I can solve it.

@theotherjimmy Could you reproduce this?

[theotherjimmy]

I think I said that, @0xc0170 , Yes.

[TomoYamanaka]

How is this going ? Any update ?

[theotherjimmy]

Thanks for reminding me @TomoYamanaka I just submitted a PR to the website to address this issue. I'll keep you posted on it's progress.

[TomoYamanaka]

@theotherjimmy

Thank you for your reply and PR.
Please let me know your PR number.

[TomoYamanaka]

@theotherjimmy

Sorry to bother you again.
Could you let me know the above PR that you submitted to the website to address this issues?

[theotherjimmy]

@TomoYamanaka I mentioned this issue in the PR I submitted to the website. If you cannot see the PR mention immediately above your comment, then I can't do anything more. I could give you a link, but you would just see a 404 error.

[TomoYamanaka]

@theotherjimmy

Thank you for your comments.
If you mentioned this issue in your PR, I guess that your PR is linked in this page.
However, I can not see your PR link in page.

Could you let me know your PR number, not link ?

[TomoYamanaka]

@theotherjimmy

I understood it thanks to @toyowata .
The PR you submitted to the website is that ARM mbed team only can access.
Also he told me that your PR was merged.
Therefore, I will comfirm whether this issue modify in current.

[robotdad]

I just hit this trying a blink sample export. I only had to modify the LD_FLAGS options per above, LD didn't have anything that offended the compiler in it.

[TomoYamanaka]

@theotherjimmy

I exported a program to GCC ARM Embedded from mbed online compiler.
But I faced the same error that I commented previous.

Was the deploy to the online environment complete?
Also, could you let me tell the difference between Makefile before and after modification?

[theotherjimmy]

@TomoYamanaka

Was the deploy to the online environment complete?

Probably. I'm working on a new version of the patch that I don't have to update every 2 weeks

Also, could you let me tell the difference between Makefile before and after modification?

I'm not going to stop you from telling me the difference. Maybe you meant to say something else.

[TomoYamanaka]

@theotherjimmy

Probably. I'm working on a new version of the patch that I don't have to update every 2 weeks

I agreed.

I'm not going to stop you from telling me the difference. Maybe you meant to say something else.

Sorry.
My intention is to confirm what Makefile would be exported after the patch would be deployed so that it would be able to check if it address the error I’m now facing.

[zou9a]

Hit same issue. Export DISCO-F746NG_blink_led to ARM GCC. Host: Windows 10 using cygwin

$ make
link: DISCO-F746NG_LCD_demo.elf
c:/program files (x86)/gnu tools arm embedded/6.2 2016q4/bin/../lib/gcc/arm-none-eabi/6.2.1/../../../../arm-none-eabi/lib/thumb/v7e-m/fpv5-sp/softfp\libc.a(lib_a-fflush.o): In function __sflush_r': fflush.c:(.text.__sflush_r+0x7c): undefined reference to__wrap__free_r'
c:/program files (x86)/gnu tools arm embedded/6.2 2016q4/bin/../lib/gcc/arm-none-eabi/6.2.1/../../../../arm-none-eabi/lib/thumb/v7e-m/fpv5-sp/softfp\libc.a(lib_a-fclose.o): In function _fclose_r': fclose.c:(.text._fclose_r+0x4a): undefined reference to__wrap__free_r'
fclose.c:(.text._fclose_r+0x58): undefined reference to __wrap__free_r' fclose.c:(.text._fclose_r+0x7a): undefined reference to__wrap__free_r'
c:/program files (x86)/gnu tools arm embedded/6.2 2016q4/bin/../lib/gcc/arm-none-eabi/6.2.1/../../../../arm-none-eabi/lib/thumb/v7e-m/fpv5-sp/softfp\libc.a(lib_a-svfprintf.o): In function _svfprintf_r': vfprintf.c:(.text._svfprintf_r+0x1068): undefined reference to__wrap__malloc_r'
c:/program files (x86)/gnu tools arm embedded/6.2 2016q4/bin/../lib/gcc/arm-none-eabi/6.2.1/../../../../arm-none-eabi/lib/thumb/v7e-m/fpv5-sp/softfp\libc.a(lib_a-mprec.o): In function _Balloc': mprec.c:(.text._Balloc+0x22): undefined reference to__wrap__calloc_r'
mprec.c:(.text._Balloc+0x3e): undefined reference to __wrap__calloc_r' c:/program files (x86)/gnu tools arm embedded/6.2 2016q4/bin/../lib/gcc/arm-none-eabi/6.2.1/../../../../arm-none-eabi/lib/thumb/v7e-m/fpv5-sp/softfp\libc.a(lib_a-svfiprintf.o): In function__ssprint_r':
vfprintf.c:(.text.__ssprint_r+0x4c): undefined reference to __wrap__malloc_r' vfprintf.c:(.text.__ssprint_r+0xbc): undefined reference to__wrap__realloc_r'
vfprintf.c:(.text.__ssprint_r+0xca): undefined reference to `__wrap__free_r'
collect2.exe: error: ld returned 1 exit status
make[1]: * [/cygdrive/c/Users/me/Downloads/DISCO-F746NG_LCD_demo_gcc_arm_disco_f746ng/DISCO-F746NG_LCD_demo/Makefile:388: DISCO-F746NG_LCD_demo.elf] Error 1
make: * [Makefile:26: all] Error 2

$ arm-none-eabi-gcc -v
Using built-in specs.
COLLECT_GCC=C:\Program Files (x86)\GNU Tools ARM Embedded\6.2 2016q4\bin\arm-none-eabi-gcc.exe
COLLECT_LTO_WRAPPER=c:/program\ files\ (x86)/gnu\ tools\ arm\ embedded/6.2\ 2016q4/bin/../lib/gcc/arm-none-eabi/6.2.1/lto-wrapper.exe
Target: arm-none-eabi
Configured with: /tmp/jenkins-GCC-6-buildandreg-54_20161216_1481890185/src/gcc/configure --build=x86_64-linux-gnu --host=i686-w64-mingw32 --target=arm-none-eabi --prefix=/tmp/jenkins-GCC-6-buildandreg-54_20161216_1481890185/install-mingw --libexecdir=/tmp/jenkins-GCC-6-buildandreg-54_20161216_1481890185/install-mingw/lib --infodir=/tmp/jenkins-GCC-6-buildandreg-54_20161216_1481890185/install-mingw/share/doc/gcc-arm-none-eabi/info --mandir=/tmp/jenkins-GCC-6-buildandreg-54_20161216_1481890185/install-mingw/share/doc/gcc-arm-none-eabi/man --htmldir=/tmp/jenkins-GCC-6-buildandreg-54_20161216_1481890185/install-mingw/share/doc/gcc-arm-none-eabi/html --pdfdir=/tmp/jenkins-GCC-6-buildandreg-54_20161216_1481890185/install-mingw/share/doc/gcc-arm-none-eabi/pdf --enable-languages=c,c++ --disable-decimal-float --disable-libffi --disable-libgomp --disable-libmudflap --disable-libquadmath --disable-libssp --disable-libstdcxx-pch --disable-nls --disable-shared --disable-threads --disable-tls --with-gnu-as --with-gnu-ld --with-headers=yes --with-newlib --with-python-dir=share/gcc-arm-none-eabi --with-sysroot=/tmp/jenkins-GCC-6-buildandreg-54_20161216_1481890185/install-mingw/arm-none-eabi --with-libiconv-prefix=/tmp/jenkins-GCC-6-buildandreg-54_20161216_1481890185/build-mingw/host-libs/usr --with-gmp=/tmp/jenkins-GCC-6-buildandreg-54_20161216_1481890185/build-mingw/host-libs/usr --with-mpfr=/tmp/jenkins-GCC-6-buildandreg-54_20161216_1481890185/build-mingw/host-libs/usr --with-mpc=/tmp/jenkins-GCC-6-buildandreg-54_20161216_1481890185/build-mingw/host-libs/usr --with-isl=/tmp/jenkins-GCC-6-buildandreg-54_20161216_1481890185/build-mingw/host-libs/usr --with-libelf=/tmp/jenkins-GCC-6-buildandreg-54_20161216_1481890185/build-mingw/host-libs/usr --with-host-libstdcxx='-static-libgcc -Wl,-Bstatic,-lstdc++,-Bdynamic -lm' --with-pkgversion='GNU Tools for ARM Embedded Processors' --with-multilib-list=rmprofile
Thread model: single
gcc version 6.2.1 20161205 (release) [ARM/embedded-6-branch revision 243739] (GNU Tools for ARM Embedded Processors)

$ make -v
GNU Make 4.2.1
Construit pour i686-pc-cygwin
Copyright (C) 1988-2016 Free Software Foundation, Inc.
Licence GPLv3+ : GNU GPL version 3 ou ultérieure http://gnu.org/licenses/gpl.html
Ceci est un logiciel libre : vous êtes autorisé à le modifier et à la redistribuer.
Il ne comporte AUCUNE GARANTIE, dans la mesure de ce que permet la loi.

[toyowata]

Hi @theotherjimmy @TomoYamanaka

I have quick tested this and it seems the build still has a problem.

How to reproduce

• Export mbed_blinky example (not mbed-os-example-blinky) from online compiler
• Build the project as below:

$ cd mbed_blinky
$ make
Compile: main.cpp
link: mbed_blinky.elf
/opt/gnuarm/gcc-arm-none-eabi-5_4-2016q3/bin/../lib/gcc/arm-none-eabi/5.4.1/../../../../arm-none-eabi/lib/armv7-ar/thumb/fpu/libc.a(lib_a-fflush.o): In function `__sflush_r':
fflush.c:(.text.__sflush_r+0x80): undefined reference to `__wrap__free_r'
/opt/gnuarm/gcc-arm-none-eabi-5_4-2016q3/bin/../lib/gcc/arm-none-eabi/5.4.1/../../../../arm-none-eabi/lib/armv7-ar/thumb/fpu/libc.a(lib_a-fclose.o): In function `_fclose_r':
fclose.c:(.text._fclose_r+0x4a): undefined reference to `__wrap__free_r'
fclose.c:(.text._fclose_r+0x58): undefined reference to `__wrap__free_r'
fclose.c:(.text._fclose_r+0x7a): undefined reference to `__wrap__free_r'
/opt/gnuarm/gcc-arm-none-eabi-5_4-2016q3/bin/../lib/gcc/arm-none-eabi/5.4.1/../../../../arm-none-eabi/lib/armv7-ar/thumb/fpu/libc.a(lib_a-svfprintf.o): In function `_svfprintf_r':
vfprintf.c:(.text._svfprintf_r+0x13d6): undefined reference to `__wrap__malloc_r'
/opt/gnuarm/gcc-arm-none-eabi-5_4-2016q3/bin/../lib/gcc/arm-none-eabi/5.4.1/../../../../arm-none-eabi/lib/armv7-ar/thumb/fpu/libc.a(lib_a-mprec.o): In function `_Balloc':
mprec.c:(.text._Balloc+0x24): undefined reference to `__wrap__calloc_r'
mprec.c:(.text._Balloc+0x40): undefined reference to `__wrap__calloc_r'
/opt/gnuarm/gcc-arm-none-eabi-5_4-2016q3/bin/../lib/gcc/arm-none-eabi/5.4.1/../../../../arm-none-eabi/lib/armv7-ar/thumb/fpu/libc.a(lib_a-svfiprintf.o): In function `__ssprint_r':
vfprintf.c:(.text.__ssprint_r+0x60): undefined reference to `__wrap__malloc_r'
vfprintf.c:(.text.__ssprint_r+0xc8): undefined reference to `__wrap__realloc_r'
vfprintf.c:(.text.__ssprint_r+0xd6): undefined reference to `__wrap__free_r'
collect2: error: ld returned 1 exit status
make[1]: *** [mbed_blinky.elf] Error 1
make: *** [all] Error 2

I confirmed that pre-build archive (static library) contains proper symbols below:

$ arm-none-eabi-nm mbed/TARGET_RZ_A1H/TOOLCHAIN_GCC_ARM/libmbed.a 

AnalogIn.o:
00000000 B _ZN4mbed8AnalogIn6_mutexE

(snip)

mbed_alloc_wrappers.o:
         U __real__calloc_r
         U __real__free_r
         U __real__malloc_r
         U __real__realloc_r
00000000 T __wrap__calloc_r
00000000 T __wrap__free_r
00000000 T __wrap__malloc_r
00000000 T __wrap__realloc_r
00000000 T mbed_stats_heap_get
         U memset

Workaround 1

I think removing --wrap options from the Makefile is not a good idea, since this is required our standard build options for GCC_ARM.
https://github.com/ARMmbed/mbed-os/blob/master/tools/profiles/release.json#L12

Workaround 2

During some hacking, I found that adding extra underscore _ for each symbols in the Makefile fixes this link errors.

[Original]

LD_FLAGS :=-Wl,--gc-sections -Wl,--wrap,main -Wl,--wrap,_malloc_r -Wl,--wrap,_free_r -Wl,--wrap,_realloc_r -Wl,--wrap,_calloc_r -Wl,--wrap,exit -Wl,--wrap,atexit -mcpu=cortex-a9 -mthumb-interwork -marm -march=armv7-a -mfpu=vfpv3 -mfloat-abi=hard -mno-unaligned-access 

[Modified]

LD_FLAGS :=-Wl,--gc-sections -Wl,--wrap,main -Wl,--wrap,__malloc_r -Wl,--wrap,__free_r -Wl,--wrap,__realloc_r -Wl,--wrap,__calloc_r -Wl,--wrap,exit -Wl,--wrap,atexit -mcpu=cortex-a9 -mthumb-interwork -marm -march=armv7-a -mfpu=vfpv3 -mfloat-abi=hard -mno-unaligned-access 

I don't have proper logical explanation why this fixed the link errors, because imported mbed classic project by mbed-cli works fine (no link errors) by mbed compile command with out any modification (it use same --wrap options).

$ mbed import https://developer.mbed.org/teams/mbed/code/mbed_blinky/
$ cd mbed_blinky
$ mbed compile -m RZ_A1H -t GCC_ARM

[theotherjimmy]

@toyowata I agree, this does not make sense when you look at it like that. However, I don't think that the mbed OS 5 build profiles always directly apply to the mbed OS 2 builds. That's why I was recommending removing the --wrap options.

[toyowata]

@theotherjimmy Are you recommending user to remove the --wrap options from Makefile by manually, rather than exporter fix? If so, can you describe this incident to the exporter document page as known issue?

https://docs.mbed.com/docs/mbed-os-handbook/en/latest/advanced/exporters/

[theotherjimmy]

@toyowata Not really. I think that we can fix this with the exporters (which is not technically where the fix is), but at the moment it requires a manual update for every release. I'm working with the web team to remove the manual step.

[theotherjimmy]

It the mean time we could put a note in that handbook page. Would you like me to do that?

[toyowata]

@theotherjimmy Yes, could you? Thanks.

[theotherjimmy]

@toyowata see https://github.com/ARMmbed/Handbook/pull/165

[toyowata]

@theotherjimmy thanks a lot for this!

[theotherjimmy]

Should we close this as a know issue now?

[toyowata]

@theotherjimmy thanks!

[JojoS62]

@theotherjimmy sorry to wake up this thread, but isn't there a better solution than just to comment this as a problem?
I suggest to include the mbed_alloc_wrappers.cpp sourcefile also when mbed is used and not mbed-dev. This file compiles without errors and the wrapper functions are available for the linker.
The positive side effect is that I can use now the mem tracing and heap stats also. Currently, the mbed_heap_size is reported as zero, but maybe this can be set for mbed2 also.

[theotherjimmy]

@JojoS62 No worries on the thread necromancy.

I don't think that mbed_alloc_wrappers.cpp is part of mbed OS 2. I think what you are suggesting is an interesting observation: mbed OS 2 could be mbed OS 5 without the RTOS. I don't know of another way to add that file to the build. Sorry, but this workaround is going to have to stay :(

[JojoS62]

@theotherjimmy This file is really part of the OS 2 build: https://developer.mbed.org/users/mbed_official/code/mbed-dev/file/e3b6fe271b81/platform/mbed_alloc_wrappers.cpp
But the export copies only the header files from the /platform directory and I guess there is no option for exceptions to this rule?

Another fix: when the symbols MBED_HEAP_STATS_ENABLED or MBED_MEM_TRACING_ENABLED are not present, then the corresponding linker flags should not be created or removed from the ld_flags list. This can happen in the exporter, but would be the same in every exporter. Is there another place to apply this rule?
These memory function wrappers are only needed when compiler GCC_ARM is used and this module is present and at least one of the STATS defines. The logic should be to add these special flags only in this case. Maybe the profiles mechanism is the place to add additional flags when symbol xy is present?

[JojoS62]

@theotherjimmy ok, the easiest solution:
I see the wrapper object file is in the libmbed.a but its a linker issue with the one-pass resolution. I ran into the same problem with some other unreferenced symbols like _getpid and _kill_r from nosys.

solution: add this magic line to the linkerscript after MEMORY(...):

GROUP ( libnosys.a libc_nano.a libmbed.a )

libc_nano maybe dependent on using nano.specs or not.

[theotherjimmy]

WOW! thanks for digging into that @JojoS62! I'll look into using that linker script magic. OTOH, I can't change old releases, so I may have to find a way to do that on the command line. Either way, you gave me a great place to start resolving this problem from!

[JojoS62]

Thanks, because I'm still on my mission to fix the LPC exporter :-) I get a working version with some manual fixes, but then the build fails and I don't know if its a exporter problem or some other stuff.

Now I have checked the makefile again, there is a LD_SYS_LIBS with a group option. When I add -lmbed as last entry to this group, building with make is successful:
generated, linker errors:
LD_SYS_LIBS :=-Wl,--start-group -lstdc++ -lsupc++ -lm -lc -lgcc -lnosys -Wl,--end-group
added -lmbed, works fine:
LD_SYS_LIBS :=-Wl,--start-group -lstdc++ -lsupc++ -lm -lc -lgcc -lnosys -lmbed -Wl,--end-group

So this should be easy to fix.

[theotherjimmy]

So this diff:?

diff --git i/tools/export/makefile/Makefile.tmpl w/tools/export/makefile/Makefile.tmpl
index 15d97f693..1337760fd 100644
--- i/tools/export/makefile/Makefile.tmpl
+++ w/tools/export/makefile/Makefile.tmpl
@@ -54,7 +54,6 @@ PROJECT := {{name}}
 {% for path in include_paths %}INCLUDE_PATHS += -I{{path}}
 {% endfor %}
 LIBRARY_PATHS :={% for p in library_paths %} {{user_library_flag}}{{p}} {% endfor %}
-LIBRARIES :={% for lib in libraries %} {{lib}} {% endfor %}
 LINKER_SCRIPT ?= {{linker_script}}
 {%- block additional_variables -%}{% endblock %}

@@ -83,7 +82,7 @@ SREC_CAT = srec_cat
 {% endfor %}

 LD_FLAGS :={%- block ld_flags -%} {{ld_flags|join(" ")}} {% endblock %}
-LD_SYS_LIBS :={%- block sys_libs -%} {{ld_sys_libs|join(" ")}} {% endblock %}
+LD_SYS_LIBS :={%- block sys_libs -%} {{ld_sys_libs|join(" ")}} {{libraries|join(" ")}} {% endblock %}

 # Tools and Flags
 ###############################################################################

[theotherjimmy]

^ Should be compatible with IAR and ARM compilers as they don't do anything fancy with libs, at least not compared to GCC.

[JojoS62]

not so easy...
this entry must not be omitted, got errors without it:
LIBRARIES := -l:libmbed.a

Then it looks like make-gcc-arm.tmpl overrides the block sys_libs, so adding libraries to the makefile.tmpl had no effect.

I added the libraries to the gcc-arm.tmpl, but the libraries list is a full filename where the linker expects the undecorated name:
LD_SYS_LIBS :=-Wl,--start-group -lstdc++ -lsupc++ -lm -lc -lgcc -lnosys -l:libmbed.a -Wl,--end-group

[JojoS62]

this creates the correct entry in the make-gcc-arm.tmpl, but don't know if its save:

{%- block sys_libs -%} -Wl,--start-group {{ld_sys_libs|join(" ")}} {% for lib in libraries %}-l{{lib[6:-2]}}{% endfor %} -Wl,--end-group {%- endblock -%}

[theotherjimmy]

@JojoS62 You're right, that patch just breaks it.

but the libraries list is a full filename where the linker expects the undecorated name:

That's supposed to be what the : there signifies. I can't find the link, but I recall that would allow me to use the filename directly without striping the lib prefix.

If you want the behavior you described, then I recommend the following patch (It also corrects the make-gcc-arm.tmpl to call the super method instead of implementing the behavior itself):

--- i/tools/export/makefile/Makefile.tmpl
+++ w/tools/export/makefile/Makefile.tmpl
@@ -54,7 +54,6 @@ PROJECT := {{name}}
 {% for path in include_paths %}INCLUDE_PATHS += -I{{path}}
 {% endfor %}
 LIBRARY_PATHS :={% for p in library_paths %} {{user_library_flag}}{{p}} {% endfor %}
-LIBRARIES :={% for lib in libraries %} {{lib}} {% endfor %}
 LINKER_SCRIPT ?= {{linker_script}}
 {%- block additional_variables -%}{% endblock %}

@@ -83,7 +82,7 @@ SREC_CAT = srec_cat
 {% endfor %}

 LD_FLAGS :={%- block ld_flags -%} {{ld_flags|join(" ")}} {% endblock %}
-LD_SYS_LIBS :={%- block sys_libs -%} {{ld_sys_libs|join(" ")}} {% endblock %}
+LD_SYS_LIBS :={%- block sys_libs -%} {{ld_sys_libs|join(" ")}} {{libraries|join(" ")}} {% endblock %}

 # Tools and Flags
 ###############################################################################
diff --git i/tools/export/makefile/__init__.py w/tools/export/makefile/__init__.py
index 913a585ed..7a031a099 100644
--- i/tools/export/makefile/__init__.py
+++ w/tools/export/makefile/__init__.py
@@ -195,7 +195,7 @@ class GccArm(Makefile):

     @staticmethod
     def prepare_lib(libname):
-        return "-l:" + libname
+        return "-l" + libname[3:-2]

     @staticmethod
     def prepare_sys_lib(libname):
diff --git i/tools/export/makefile/make-gcc-arm.tmpl w/tools/export/makefile/make-gcc-arm.tmpl
index 3b89b294a..6c73d698a 100644
--- i/tools/export/makefile/make-gcc-arm.tmpl
+++ w/tools/export/makefile/make-gcc-arm.tmpl
@@ -1,6 +1,6 @@
 {% extends "makefile/Makefile.tmpl" %}

-{%- block sys_libs -%} -Wl,--start-group {{ld_sys_libs|join(" ")}} -Wl,--end-group {%- endblock -%}
+{%- block sys_libs -%} -Wl,--start-group {{ super() }}  -Wl,--end-group {%- endblock -%}

 {% block elf2bin %}
        $(ELF2BIN) -O binary $< $@

[theotherjimmy]

More correctly, on the python modifications:

diff --git i/tools/export/makefile/__init__.py w/tools/export/makefile/__init__.py
index 913a585ed..f034c113b 100644
--- i/tools/export/makefile/__init__.py
+++ w/tools/export/makefile/__init__.py
@@ -195,7 +195,9 @@ class GccArm(Makefile):

     @staticmethod
     def prepare_lib(libname):
-        return "-l:" + libname
+        if "lib" == libname[:3]:
+            libname = libname[3:]
+        return "-l" + splitext(libname)[0]

     @staticmethod
     def prepare_sys_lib(libname):

[theotherjimmy]

BTW, that makefile works for mbed OS 5 stuff.

[JojoS62]

yes, but works also for OS 2, I see no difference.

will continue tomorrow, its late here. Thanks Jimmy

[theotherjimmy]

yes, but works also for OS 2, I see no difference.

That was the point, actually. It should be the same as your change, but it's more in line with what I would like.

Glad to see that you're making progress. You're welcome. Just ping me if you need anything, I'll get to it when I wake up.

[JojoS62]

@theotherjimmy I've tried these modifications and they worked for OS 2.
https://github.com/JojoS62/mbed-os/compare/master...JojoS62:fix_make_GCC_ARM_exporter?expand=1
These are the same modifications in OS 5, but this does not use the pre-compiled libs, so it should not fail. Is this ok for a PR?

[theotherjimmy]

@JojoS62 I think that would include a precompiled library twice.

Also, I would like to have the check for the starting "lib" in there as there are no guarantees that it will be present. We can assume that ".a" is the suffix because that's what we scan for.

HOWEVER, I would prefer to have the PR anyway, so that we can have this discussion on the PR :smile:

[theotherjimmy]

Glad to see that you're making progress. You're welcome.

facepalm I should have edited that. It comes off as very egotistical. I was just trying to respond to your stuff in order...

[JojoS62]

ok.
Adding -lmbed to LIBRARIES and the group gave no error.
Adding -lmbed only to the group gives errors. I don't know who understands the linker stuff really...

Don't worry, everything is fine. I like to work on this great project, even the start is very hard.

[theotherjimmy]

Adding -lmbed to LIBRARIES and the group gave no error.Adding -lmbed only to the group gives errors.

Sounds like you have the correct solution. Ship it. Let's have that PR.

I don't know who understands the linker stuff really...

Not me, not the people who wrote the linker...

Don't worry, everything is fine.

:+1:

I like to work on this great project, even the start is very hard.

The first part is great to hear, the second troubling. Let me know if there's anything I can do to make it easier.

[ensonic]

Has this fix been released? I am a new user to mbed and this is what I did:

sudo apt install gcc-arm-none-eabi
sudo pip2 install mbed-cli
mbed config -G ARM_PATH "/usr/bin/"
mbed import https://[email protected]/teams/Pokitto-Community-Team/code/Bitmap/
cd Bitmap
mbed toolchain GCC_ARM
mbed target LPC11U68
mbed compile
Building project Bitmap (LPC11U68, GCC_ARM)
Scan: .
Scan: env
Scan: mbed
Link: Bitmap
./BUILD/LPC11U68/GCC_ARM/PokittoLib/mbed-pokitto/common/error.o: In function `error':
error.c:(.text.error+0x6): undefined reference to `__wrap_exit'
./BUILD/LPC11U68/GCC_ARM/PokittoLib/mbed-pokitto/common/retarget.o: In function `__cxa_pure_virtual':
retarget.cpp:(.text.__cxa_pure_virtual+0x4): undefined reference to `__wrap_exit'
/usr/lib/gcc/arm-none-eabi/5.4.1/../../../arm-none-eabi/lib/armv6-m/libc_nano.a(lib_a-malloc.o): In function `malloc':
/build/newlib-XAuz1P/newlib-2.4.0.20160527/build_nano/arm-none-eabi/armv6-m/newlib/libc/stdlib/../../../../../../newlib/libc/stdlib/malloc.c:215: undefined reference to `__wrap__malloc_r'
/usr/lib/gcc/arm-none-eabi/5.4.1/../../../arm-none-eabi/lib/armv6-m/libc_nano.a(lib_a-malloc.o): In function `free':
/build/newlib-XAuz1P/newlib-2.4.0.20160527/build_nano/arm-none-eabi/armv6-m/newlib/libc/stdlib/../../../../../../newlib/libc/stdlib/malloc.c:222: undefined reference to `__wrap__free_r'
collect2: error: ld returned 1 exit status
[ERROR] ./BUILD/LPC11U68/GCC_ARM/PokittoLib/mbed-pokitto/common/error.o: In function `error':
error.c:(.text.error+0x6): undefined reference to `__wrap_exit'
./BUILD/LPC11U68/GCC_ARM/PokittoLib/mbed-pokitto/common/retarget.o: In function `__cxa_pure_virtual':
retarget.cpp:(.text.__cxa_pure_virtual+0x4): undefined reference to `__wrap_exit'
/usr/lib/gcc/arm-none-eabi/5.4.1/../../../arm-none-eabi/lib/armv6-m/libc_nano.a(lib_a-malloc.o): In function `malloc':
/build/newlib-XAuz1P/newlib-2.4.0.20160527/build_nano/arm-none-eabi/armv6-m/newlib/libc/stdlib/../../../../../../newlib/libc/stdlib/malloc.c:215: undefined reference to `__wrap__malloc_r'
/usr/lib/gcc/arm-none-eabi/5.4.1/../../../arm-none-eabi/lib/armv6-m/libc_nano.a(lib_a-malloc.o): In function `free':
/build/newlib-XAuz1P/newlib-2.4.0.20160527/build_nano/arm-none-eabi/armv6-m/newlib/libc/stdlib/../../../../../../newlib/libc/stdlib/malloc.c:222: undefined reference to `__wrap__free_r'
collect2: error: ld returned 1 exit status

[mbed] ERROR: "/usr/bin/python" returned error code 1.
[mbed] ERROR: Command "/usr/bin/python -u /home/ensonic/projects/pokitto/Bitmap/.temp/tools/make.py -t GCC_ARM -m LPC11U68 --source . --build ./BUILD/LPC11U68/GCC_ARM" in "/home/ensonic/projects/pokitto/Bitmap"
---

If I edit the makefile as suggested above, it does not show any effect. Also if I change all files that contain those strings, it still fails the same way. To this point I am not sure how the makefiles interact with the profiles.
Building those project online works.

[theotherjimmy]

Hi @ensonic

You're commenting on a closed issue.

mbed compile does not use a makefile whatsoever; this issue discusses a makefile because it is using mbed export.

Please open a new issue, as what you have noticed has very different steps to reproduce.

[theotherjimmy]

To directly answer you question:

Has this fix been released?

That fix went into Mbed OS 5.5.5, which is already released. You may be using a version of Mbed OS prior to that version, but as I mentioned in my prior comment, I don't think this is the same bug.

---

Also,

To this point I am not sure how the makefiles interact with the profiles.

Your analysis is correct: The Makefiles do nothing with respect to mbed compile

[ensonic]

Thanks for the replies. Posted #6206. I've got here, since the compilation errors are the same.

[apluscw]

Just a quick heads up. I exported the SX1272 PingPong project to a Kinetis MCU and did not see this issue. However, it did show up when I exported the same project for the nRF52 Dev Kit. It was resolved by manually adding the underscores in the linker settings as described in Workaround 2.

PS - Same thing happened on a Nucleo-L073RZ board.