Important changes to forums

We’re making some changes to the Mbed forums. From 10th December 2019 all new discussions will take place on our new forum site. You can continue to reply to existing threads for the next two weeks. After that we will archive this forum so you can return to useful posts in the future.

Offline GCC compiler works with mbed libraries!

06 Aug 2012

Do you get a prompt for a Authentication Realm password at this time?

No, I did not get it.

06 Aug 2012

Adam Green wrote:

Thierry, just try rerunning the existing script. Don't attempt to use Dan's Mercurial suggestion. That won't be compatible with the current master branch of the gcc4mbed project.

May I need to start from the beginning, downloading the first file?

06 Aug 2012

I would recommend starting over again with downloading the .zip from github, extracting it, and running win_install.cmd

If you hang at the same place again, press ENTER, and then wait for about a half minute to see if it finishes pulling down the necessary files. If it still hangs, CTRL+C out of it and paste up the contents of the win_install.log, escaped with <<code>>...<</code>> flags as I mentioned before.

07 Aug 2012

Thanks! Now, it is installed. Solution is effectively to press Enter. I did it more than once.

07 Aug 2012

That's good to hear! I will update the scripts to show a message at this stage indicating that the user might need to press ENTER if they see no progress after a minute. In the future I will switch to the Mercurial repository that Dan mentioned.

The problem is that I redirect stdout to win_install.log so that I can diagnose any failures that people might encounter but that means the message to provide the password also gets redirected to the log file so that people can't see it. I tried turning off the redirection for this stage but its output is pretty overwhelming so I didn't think that was a good solution.

08 Aug 2012

I exported my project from the online compiler to a zip file. I created a simple makefile by copying the one from HelloWorld And I tried. Ok, please do not comment warnings. But please help me to solve the error at the end. Here is the logs

C:\Users\thierry\Downloads\adamgreen-gcc4mbed-f5adc35\samples\CAN0059>make clean
 all
cs-rm -f ../../src/gcc4mbed.o ../../src/syscalls.o  ./SDHCFileSystem.o ./main.o
./PowerControl/EthernetPowerControl.o ./SMARTGPU/SMARTGPU.o
cs-rm -f CANHSD.hex
cs-rm -f CANHSD.elf
cs-rm -f CANHSD.map
cs-rm -f CANHSD.bin
cs-rm -f CANHSD.disasm
arm-none-eabi-g++ -O2 -gdwarf-2 -mcpu=cortex-m3 -mthumb -mthumb-interwork -fshor
t-wchar -ffunction-sections -fdata-sections -fpromote-loop-indices -Wall -Wextra
 -Wimplicit -Wcast-align -Wpointer-arith -Wredundant-decls -Wshadow -Wcast-qual
-Wcast-align -fno-exceptions -I./ -I./FATFileSystem/ -I./FATFileSystem/LPC1768/
-I./FATFileSystem/LPC2368/ -I./PowerControl/ -I./SMARTGPU/ -I../../external/mbed
 -I../../external/mbed/LPC1768 -I../../external/FATFileSystem -DTARGET_LPC1768 -
DGCC4MBED_DELAYED_STDIO_INIT=1 -c ../../src/gcc4mbed.c -o ../../src/gcc4mbed.o
arm-none-eabi-g++ -O2 -gdwarf-2 -mcpu=cortex-m3 -mthumb -mthumb-interwork -fshor
t-wchar -ffunction-sections -fdata-sections -fpromote-loop-indices -Wall -Wextra
 -Wimplicit -Wcast-align -Wpointer-arith -Wredundant-decls -Wshadow -Wcast-qual
-Wcast-align -fno-exceptions -I./ -I./FATFileSystem/ -I./FATFileSystem/LPC1768/
-I./FATFileSystem/LPC2368/ -I./PowerControl/ -I./SMARTGPU/ -I../../external/mbed
 -I../../external/mbed/LPC1768 -I../../external/FATFileSystem -DTARGET_LPC1768 -
DGCC4MBED_DELAYED_STDIO_INIT=1 -c ../../src/syscalls.c -o ../../src/syscalls.o
arm-none-eabi-g++ -O2 -gdwarf-2 -mcpu=cortex-m3 -mthumb -mthumb-interwork -fshor
t-wchar -ffunction-sections -fdata-sections -fpromote-loop-indices -Wall -Wextra
 -Wimplicit -Wcast-align -Wpointer-arith -Wredundant-decls -Wshadow -Wcast-qual
-Wcast-align -fno-exceptions -I./ -I./FATFileSystem/ -I./FATFileSystem/LPC1768/
-I./FATFileSystem/LPC2368/ -I./PowerControl/ -I./SMARTGPU/ -I../../external/mbed
 -I../../external/mbed/LPC1768 -I../../external/FATFileSystem -DTARGET_LPC1768 -
DGCC4MBED_DELAYED_STDIO_INIT=1 -c SDHCFileSystem.cpp -o SDHCFileSystem.o
SDHCFileSystem.cpp: In constructor 'SDFileSystem::SDFileSystem(PinName, PinName,
 PinName, PinName, const char*)':
SDHCFileSystem.cpp:130:98: warning: declaration of 'name' shadows a member of 't
his'
SDHCFileSystem.cpp: In member function 'int SDFileSystem::_sd_sectors()':
SDHCFileSystem.cpp:474:107: warning: format '%.ld' expects type 'long int', but
argument 3 has type 'int'
SDHCFileSystem.cpp:474:107: warning: format '%.ld' expects type 'long int', but
argument 3 has type 'int'
arm-none-eabi-g++ -O2 -gdwarf-2 -mcpu=cortex-m3 -mthumb -mthumb-interwork -fshor
t-wchar -ffunction-sections -fdata-sections -fpromote-loop-indices -Wall -Wextra
 -Wimplicit -Wcast-align -Wpointer-arith -Wredundant-decls -Wshadow -Wcast-qual
-Wcast-align -fno-exceptions -I./ -I./FATFileSystem/ -I./FATFileSystem/LPC1768/
-I./FATFileSystem/LPC2368/ -I./PowerControl/ -I./SMARTGPU/ -I../../external/mbed
 -I../../external/mbed/LPC1768 -I../../external/FATFileSystem -DTARGET_LPC1768 -
DGCC4MBED_DELAYED_STDIO_INIT=1 -c main.cpp -o main.o
main.cpp: In function 'int main()':
main.cpp:173:62: warning: array subscript has type 'char'
main.cpp: In function 'void init()':
main.cpp:218:24: warning: declaration of 'str' shadows a global declaration
main.cpp:108:22: warning: shadowed declaration is here
main.cpp: In function 'void watchdog()':
main.cpp:545:48: warning: suggest parentheses around '&&' within '||'
main.cpp: In function 'void can_check()':
main.cpp:706:37: warning: array subscript has type 'char'
main.cpp:706:57: warning: array subscript has type 'char'
main.cpp: In function 'void calc_g2(int, char*)':
main.cpp:782:94: warning: operation on 'i' may be undefined
main.cpp:794:94: warning: operation on 'i' may be undefined
main.cpp:851:85: warning: operation on 'i' may be undefined
main.cpp:851:85: warning: operation on 'i' may be undefined
main.cpp:851:85: warning: operation on 'i' may be undefined
main.cpp:851:85: warning: operation on 'i' may be undefined
main.cpp:867:64: warning: operation on 'i' may be undefined
main.cpp:879:86: warning: operation on 'i' may be undefined
main.cpp:924:22: warning: declaration of 'i' shadows a previous local
main.cpp:755:9: warning: shadowed declaration is here
main.cpp:932:22: warning: declaration of 'i' shadows a previous local
main.cpp:755:9: warning: shadowed declaration is here
main.cpp:940:22: warning: declaration of 'i' shadows a previous local
main.cpp:755:9: warning: shadowed declaration is here
main.cpp: In function 'void calc_g3(int, char*)':
main.cpp:995:17: warning: unused variable 'acc_ped'
main.cpp:1007:17: warning: unused variable 'fuel_lvl'
main.cpp:1021:21: warning: unused variable 'n'
main.cpp:1042:21: warning: unused variable 'n'
main.cpp:1050:21: warning: unused variable 'n'
main.cpp:1068:21: warning: unused variable 'n'
main.cpp:1077:21: warning: unused variable 'n'
main.cpp:1088:21: warning: unused variable 'n'
main.cpp:1130:21: warning: unused variable 'n'
main.cpp:1138:21: warning: unused variable 'n'
main.cpp:965:16: warning: unused variable 'p_ice_t'
main.cpp:965:25: warning: unused variable 'p_ice_rpm'
main.cpp:965:36: warning: unused variable 'p_ice_kw'
PowerControl/EthernetPowerControl.h: At global scope:
PowerControl/EthernetPowerControl.h:16:23: warning: 'short unsigned int read_PHY
(unsigned int)' declared 'static' but never defined
PowerControl/EthernetPowerControl.h:17:13: warning: 'void write_PHY(unsigned int
, short unsigned int)' declared 'static' but never defined
arm-none-eabi-g++ -O2 -gdwarf-2 -mcpu=cortex-m3 -mthumb -mthumb-interwork -fshor
t-wchar -ffunction-sections -fdata-sections -fpromote-loop-indices -Wall -Wextra
 -Wimplicit -Wcast-align -Wpointer-arith -Wredundant-decls -Wshadow -Wcast-qual
-Wcast-align -fno-exceptions -I./ -I./FATFileSystem/ -I./FATFileSystem/LPC1768/
-I./FATFileSystem/LPC2368/ -I./PowerControl/ -I./SMARTGPU/ -I../../external/mbed
 -I../../external/mbed/LPC1768 -I../../external/FATFileSystem -DTARGET_LPC1768 -
DGCC4MBED_DELAYED_STDIO_INIT=1 -c PowerControl/EthernetPowerControl.cpp -o Power
Control/EthernetPowerControl.o
arm-none-eabi-g++ -O2 -gdwarf-2 -mcpu=cortex-m3 -mthumb -mthumb-interwork -fshor
t-wchar -ffunction-sections -fdata-sections -fpromote-loop-indices -Wall -Wextra
 -Wimplicit -Wcast-align -Wpointer-arith -Wredundant-decls -Wshadow -Wcast-qual
-Wcast-align -fno-exceptions -I./ -I./FATFileSystem/ -I./FATFileSystem/LPC1768/
-I./FATFileSystem/LPC2368/ -I./PowerControl/ -I./SMARTGPU/ -I../../external/mbed
 -I../../external/mbed/LPC1768 -I../../external/FATFileSystem -DTARGET_LPC1768 -
DGCC4MBED_DELAYED_STDIO_INIT=1 -c SMARTGPU/SMARTGPU.cpp -o SMARTGPU/SMARTGPU.o
SMARTGPU/SMARTGPU.cpp: In member function 'unsigned char SMARTGPU::icon(int, int
, int, int, char*)':
SMARTGPU/SMARTGPU.cpp:295:73: warning: declaration of 'icon' shadows a member of
 'this'
arm-none-eabi-g++ -mcpu=cortex-m3 -mthumb -O2 -Wl,-Map=CANHSD.map,--cref,--gc-se
ctions,--no-wchar-size-warning -T../../build/mbed.ld -L ../../external/gcc/LPC17
68 ../../src/gcc4mbed.o ../../src/syscalls.o  ./SDHCFileSystem.o ./main.o ./Powe
rControl/EthernetPowerControl.o ./SMARTGPU/SMARTGPU.o  ../../external/mbed/LPC17
68/mbed.ar ../../external/mbed/LPC1768/capi.ar ../../external/FATFileSystem/LPC1
768/FATFileSystem.ar  -o CANHSD.elf
./SDHCFileSystem.o:(.rodata._ZTV12SDFileSystem+0x30): undefined reference to `mb
ed::FATFileSystem::mkdir(char const*, unsigned int)'
collect2: ld returned 1 exit status
cs-make: *** [CANHSD.elf] Error 1

C:\Users\thierry\Downloads\adamgreen-gcc4mbed-f5adc35\samples\CAN0059>
08 Aug 2012

Without having access to the sources that you have in the online compiler and/or the .zip you exported, I can't really tell you how to fix the problem but I do see why you are getting the link error. It appears that your project has a FATFileSystem subdirectory which contains headers but not the sources for the library itself (but I am guessing that its LPC1768 sub-directory does contain a precompiled library.) When your code builds, it uses these headers for the FATFileSystem and then gcc4mbed attempts to link an older version of library that it has pulled down from the mbed Subversion repository. This version of the FATFileSystem library doesn't match the newer FATFileSystem headers that are part of your project.

Maybe you don't need to use gcc4mbed at all? If you checkout this mbed Handbook page you will see instructions on exporting to the GCC ARM Embedded toolchain. If you download and install this version of GCC from https://launchpad.net/gcc-arm-embedded/4.6/2011-q4-major then you can just select the GCC (ARM Embedded) option from the online compiler's project export dialog. The .zip that this exports will include a generated makefile that you should just be able to use with the GCC ARM Embedded toolchain.

Hope that helps,

Adam

12 Aug 2012

A new version of GCC4MBED project is available up on the github site at https://github.com/adamgreen/gcc4mbed#quick-start

Features include:

  • Upgraded GNU tools from Code Sourcery G++ Lite 2011.03-42 to GCC ARM Embedded 4.6-2012-q1-update.
  • Upgraded mbed SDK from revision 28 to revision 43. This newer revision of the mbed SDK was actually built by the mbed team using GCC so less hacks are now required in the GCC4MBED makefiles and linker scripts.
  • Now includes the ability to use the GNU debugger, GDB, to debug the resulting binaries on your mbed 1768 device. More information about this debugging feature can be found here: https://github.com/adamgreen/mri/blob/master/notes/mri-getting-started.creole#installation
  • Improved incremental builds through the use of header dependency tracking.

I have tried out the new installers and performed test builds on:

  • OS X Lion
  • Windows 7
  • Ubuntu 12.04

The previous version of GCC4MBED is archived here: https://github.com/adamgreen/gcc4mbed/tree/cs2011.03-42_mbed28

28 Aug 2012

I just updated the lastest release of GCC4MBED to handle the fact that the mbed SDK libraries and headers can no longer be downloaded using Subversion and Mercurial needs to be used instead. If you have tried to install GCC4MBED over the last week and it failed to install, this was likely the cause.

Thanks to Dan Ros for pointing out a few replies back in this thread that this change was happening and for Jonathon Fletcher who actually sent me the necessary GCC4MBED changes to make.

-Adam

29 Aug 2012

I just pushed up a GCC4MBED update to treat .c files as C code and not C++ to match the recent online compiler changes.

-Adam

14 Nov 2012

In trying to build gcc4mbed using a recent arm compiler from https://launchpad.net/gcc-arm-embedded (version 4.6-2012-q4-update) I get the following error "multiple definition of `aeabi_unwind_cpp_pr0'". I would be grateful for any help here (complete log is given below). Does aeabi_unwind_cpp_pr0 need to be redefined in gcc4mbed.c ?

make  -C samples

make[1]: Entering directory `/home/bt/docs/lab/components/arm/Mbed/debian/gcc4mbed-20121013/samples'

make  -C HelloWorld

make[2]: Entering directory `/home/bt/docs/lab/components/arm/Mbed/debian/gcc4mbed-20121013/samples/HelloWorld'

mkdir -p LPC176x/./ > /dev/null 2>&1 ; exit 0

arm-none-eabi-g++ -O2 -g -mcpu=cortex-m3 -mthumb -mthumb-interwork  -ffunction-sections -fdata-sections  -fno-exceptions -fno-delete-null-pointer-checks -I./ -I../../mri -I../../external/mbed -I../../external/mbed/LPC1768 -DTARGET_LPC1768 -DMRI_ENABLE=0 -DMRI_INIT_PARAMETERS='"MRI_UART_MBED_USB"'  -DMRI_BREAK_ON_INIT=1 -DMRI_SEMIHOST_STDIO=0 -MMD -MP -Wall -Wextra -Wno-unused-parameter -Wcast-align -Wpointer-arith -Wredundant-decls -Wcast-qual -Wcast-align -c main.cpp -o LPC176x/./main.o

mkdir -p LPC176x/ > /dev/null 2>&1 ; exit 0

arm-none-eabi-g++ -O2 -g -mcpu=cortex-m3 -mthumb -mthumb-interwork  -ffunction-sections -fdata-sections  -fno-exceptions -fno-delete-null-pointer-checks -I./ -I../../mri -I../../external/mbed -I../../external/mbed/LPC1768 -DTARGET_LPC1768 -DMRI_ENABLE=0 -DMRI_INIT_PARAMETERS='"MRI_UART_MBED_USB"'  -DMRI_BREAK_ON_INIT=1 -DMRI_SEMIHOST_STDIO=0 -MMD -MP -Wall -Wextra -Wno-unused-parameter -Wcast-align -Wpointer-arith -Wredundant-decls -Wcast-qual -Wcast-align -c ../../src/gcc4mbed.c -o LPC176x/gcc4mbed.o

arm-none-eabi-g++ -mcpu=cortex-m3 -mthumb -O2 -specs=../../build/startfile.spec -Wl,-Map=LPC176x/HelloWorld.map,--cref,--gc-sections,--wrap=_isatty -T../../build/mbed.ld  -L ../../external/gcc/LPC1768   LPC176x/./main.o LPC176x/gcc4mbed.o   ../../external/mbed/LPC1768/GCC_ARM/startup_LPC17xx.o ../../external/mbed/LPC1768/GCC_ARM/cmsis_nvic.o ../../external/mbed/LPC1768/GCC_ARM/core_cm3.o ../../external/mbed/LPC1768/GCC_ARM/system_LPC17xx.o ../../external/mbed/LPC1768/GCC_ARM/libmbed.a ../../external/mbed/LPC1768/GCC_ARM/libcapi.a -lstdc++ -lsupc++ -lm -lgcc -lc -lgcc -lc -lnosys  -o HelloWorld.elf

/usr/bin/../lib/gcc/arm-none-eabi/4.6.2/armv7-m/libgcc.a(unwind-arm.o): In function `__aeabi_unwind_cpp_pr0':(.text+0x648): multiple definition of `__aeabi_unwind_cpp_pr0'

LPC176x/gcc4mbed.o:/home/bt/docs/lab/components/arm/Mbed/debian/gcc4mbed-20121013/samples/HelloWorld/../../src/gcc4mbed.c:102: first defined here

collect2: ld returned 1 exit status

- Thomas

14 Nov 2012

The master branch of the gcc4mbed project is currently optimized for the 4.6-2012-q1-update of that tool chain. Using any other version of GCC isn't recommended.

Empty versions of those unwind functions are included in gcc4mbed.c to reduce the size of the binaries. Removing them from that location may provide you with a temporary workaround to this link issue until I properly re-optimize the project for a more recent version of the GNU tools.

-Adam

06 Dec 2012

I'm trying to compile some code that work on the online compiler, but not on the GCC4mbed. It is code related to the 3pi robot. The offending line of code is unsigned char arg = 0x7f * abs(speed); where speed is a float. This works ok for the online, but gcc4mbed gives me this error

m3pi/m3pi.cpp: In member function 'void m3pi::motor(int, float)': m3pi/m3pi.cpp:91:41: error: call of overloaded 'abs(float&)' is ambiguous m3pi/m3pi.cpp:91:41: note: candidates are: c:\gcc4mbed\gcc-arm-none-eabi\bin\../lib/gcc/arm-none-eabi/4.6.2/../../../../arm-none-eabi/include/stdlib.h:63:5: note: int abs(int) c:\gcc4mbed\gcc-arm-none-eabi\bin\../lib/gcc/arm-none-eabi/4.6.2/../../../../arm-none-eabi/include/c++/4.6.2/cstdlib:139:3: note: long int std::abs(long int)

I understand the problem, any idea where I get ABS that will take a float?

06 Dec 2012

Lester (Ringo) Davis wrote:

any idea where I get ABS that will take a float?

fabs

HTH, Emilio

06 Dec 2012

next question. I'm using MODSERIAL, but it gives me an error as well.

MODSERIAL/INIT.cpp: In member function 'void AjK::MODSERIAL::init(int, int)': MODSERIAL/INIT.cpp:41:12: error: '_serial' was not declared in this scope MODSERIAL/INIT.cpp:61:51: error: 'SerialIrq' was not declared in this scope MODSERIAL/INIT.cpp:69:61: error: expected ')' before 'TxIrq'

in main.cpp I have

MODSERIAL blueTooth(p13, p14);

and in main()

blueTooth.baud(115200); blueTooth.attach(&rxCallback, MODSERIAL::RxIrq);

the callback is above main and starts like this void rxCallback(MODSERIAL_IRQ_INFO *q) { char c; MODSERIAL *serial = q->serial; c=serial->rxGetLastChar();

what I'm I doing wrong?

10 Jan 2013

A new version of GCC4MBED project is available up on the github site at https://github.com/adamgreen/gcc4mbed#quick-start

Features include:

  • Upgraded GNU tools to the latest GCC ARM Embedded 4.7-2012-q4-major.
  • Upgraded mbed SDK from revision 43 to revision 54.
  • Now uses the newlib nano feature available in the latest GCC ARM Embedded tool chain to further reduce binary size. The size optimized libraries that were previously included as part of the GCC4MBED project are no longer needed and have been removed. If you don't need floating point support from scanf() and printf() routines in your program then you can reduce your binary size by setting NO_FLOAT_SCANF and NO_FLOAT_PRINTF make variables to 1. See samples/HelloWorld/makefile for an example.
  • Includes TCPSocket_HelloWorld sample from http://mbed.org/users/mbed_official/code/TCPSocket_HelloWorld/ that contains patches to networking and RTOS libraries to work with GCC.
  • OS X binaries for GCC ARM Embedded toolchain are now provided on official download site. mac_install script now installs these official binaries rather than ones built on my Mac.
  • Less verbose output during build process.
  • Still includes the ability to use the GNU debugger, GDB, to debug the resulting binaries on your mbed 1768 device. More information about this debugging feature can be found here: https://github.com/adamgreen/mri/blob/master/notes/mri-getting-started.creole#installation

I have tried out the new installers and performed test builds on:

  • OS X Lion
  • Windows 7
  • Ubuntu 12.04

The previous version of GCC4MBED is archived here: https://github.com/adamgreen/gcc4mbed/tree/gcc4.6-2012-q1_mbed43

14 Jan 2013

B Thomas wrote:

I get the following error "multiple definition of `aeabi_unwind_cpp_pr0'". I would be grateful for any help here (complete log is given below). Does aeabi_unwind_cpp_pr0 need to be redefined in gcc4mbed.c ?

I hit this issue earlier in the week when building a program which used iostream functionality from the C++ standard library. I have removed the aeabi_unwind_cpp_pr*() functions from gcc4mbed.c and see that it no longer results in larger binary size when using the newlib nano library. The GCC4MBED project on github now contains the fix for this issue.

27 Jan 2013

It is worth noting that newlib nano does not support 64bit integers in printf/scanf. See here for more. I was using a uint64_t as a unique id, which is how I discovered this.

27 Jan 2013

Jonathon, what do you feel is the best solution for this? I checked that link you included above and it doesn't seem like there is a simple solution that gives us 64-bit support and still lets us use the newlib nano libs.

I could add a MAKE variable that switches back to the standard newlib library but then we would have no size optimization at all and the resulting binaries would be pretty big. As an alternative, I could produce size optimized versions of the newlib libraries and include them in GCC4MBED as I did in previous versions.

Your thoughts?

Thanks,

Adam

27 Jan 2013

I will investigate another solution next week as well. I have the newlib nano code building on my MacBook Air. I will try to add support for 64-bit ints to it without blowing the code size up too much. That would probably be the best solution.

-Adam

27 Jan 2013

Adam Green wrote:

I will investigate another solution next week as well. I have the newlib nano code building on my MacBook Air. I will try to add support for 64-bit ints to it without blowing the code size up too much. That would probably be the best solution.

-Adam

Adam,

I like this proposed solution the best apart from the extra work that it requires from you. I really do like the smaller object sizes.

I think that 64bit (signed/unsigned) integer printf/scanf is a different requirement to 64bit float/double printf/scanf. I do not know of any cases where I would be using 64bit floating point string io.

If you do add the 64bit int support, is it worth having defines in the style of NO_FLOAT_SCANF/NO_FLOAT_PRINTF for 64bit integer support (NO_LL_SCANF/NO_LL_PRINTF).

Regards,
Jonathon

28 Mar 2013

for the offline compiler, is anyone able to change the starting address of the bin file to say 0x1000?

im looking to implement secondary usb bootloader, http://mbed.org/forum/mbed/topic/2532/

29 Mar 2013

Jonathan, in the GCC4MBED project, you want to look at this line in the linker script.

You should be able to change it from:

  FLASH (rx) : ORIGIN = 0x00000000, LENGTH = 512K

to:

  FLASH (rx) : ORIGIN = 0x00001000, LENGTH = 512K - 0x1000

If you export your project from the online compiler to be built with GCC_ARM, it should have a similar .ld file that you can make the same change to.

Hope that helps,

Adam

29 Jul 2013

With the risk that this is already solved or that this is the wrong thread, I'd like to share some tweaks in the build.bat file of mine in order to handle the errors so VisualStudio error/warning will work.

1: get "sed" from gnuwin32

2: add the following to your batch file

set SED_LINENUMBERS=-e "s/:\([0-9]\+\):\([0-9]\+\)/(\1,\2)/g"
set SED_1=-e "s/^ *from //"
set SED_2=-e "s/^In file included from //"
set SED_3=-e "s#^.*[/\]\([A-Za-z]:\)#\1#g"
set SED_4=-e "/.*: In / d"
set SED_DRIVE=-e "s#/cygdrive/\([A-Za-z]\)#\1:#g"
set SED_ERROR_1=-e "s/\*\*\* No rule to make target/error : *** No rule to make target/"
set SED_ERROR_2=-e "s/ Error \([0-9]\)/ error : \1/"
set SED_COMMAND=%PATH_OF_YOUR_GNU_ROOT%\GnuWin32\bin\sed.exe -u %SED_LINENUMBERS% %SED_1% %SED_2% %SED_3% %SED_4% %SED_DRIVE% %SED_ERROR_1% %SED_ERROR_2%

make -f makefile %1 %2  2>&1 | %SED_COMMAND%

3: update your make targets with realpath

$(Q) $(GPP) $(GPFLAGS) -c $(realpath $<) -o $@
and
$(Q) $(GCC) $(GCFLAGS) -c $(realpath $<) -o $@	

My 2 cents, Salu2

11 Sep 2013

Hi,

I'm working with an LPC1768 and i'm trying to use the C library function malloc_stats but the linker displays an error of multiple definitions.

The program is the following:

#include <malloc.h>

int main()
{
         malloc_stats();
         char* c = new char[100];
         c[99] = 'a';
         malloc_stats();
         return 0;
}

and the error is the following:

/home/admin/mbed/gcc-arm-none-eabi/bin/../lib/gcc/arm-none-eabi/4.7.3/../../../../arm-none-eabi/lib/armv7-m/libc.a(lib_a-mallocr.o): In function `_malloc_r': mallocr.c:(.text._malloc_r+0x0): multiple definition of `_malloc_r' /home/admin/mbed/gcc-arm-none-eabi/bin/../lib/gcc/arm-none-eabi/4.7.3/../../../../arm-none-eabi/lib/armv7-m/libc_s.a(lib_a-mallocr.o):mallocr.c:(.text._malloc_r+0x0): first defined here collect2: error: ld returned 1 exit status

11 Sep 2013

Hello Gustavo,

There are two things going on here.

  1. gcc4mbed now uses newlib-nano for the C standard library to produce smaller binaries. This version of newlib doesn't support the malloc_stats() call.
  2. You get the "multiple definition" error from the linker because of something that I did wrong in the gcc4mbed makefiles which allows a mix of newlib standard and newlib-nano to be linked in.

Unfortunately, even after I fix my makefile issue, you will still get an 'undefined reference' linker error since it won't be able to find any definitions of the required _malloc_stats_r() function once only newlib-nano is used. In the future I hope to port some of my heap tagging extensions into gcc4mbed. These allow dumping of the heap from within the GDB debugger. You can see used and free locations in the heap and even get the name of the caller who made each allocation. I have had this working in the past for newlib but I need to do some porting as newlib-nano uses a different (simpler) heap structure.

12 Sep 2013

Hi All,

After a long time of no mBed programming i downloaded the latest off-line compiler, exported my program but compilation stops on the first couple of lines.

fatal error: string: No such file or directory

#include <string>
#include <vector>
#include <ctype.h>

Any suggestions how to get past this point?

regards Wim van der Vegt

12 Sep 2013

Adam Green wrote:

Hello Gustavo,

There are two things going on here.

  1. gcc4mbed now uses newlib-nano for the C standard library to produce smaller binaries. This version of newlib doesn't support the malloc_stats() call.
  2. You get the "multiple definition" error from the linker because of something that I did wrong in the gcc4mbed makefiles which allows a mix of newlib standard and newlib-nano to be linked in.

Unfortunately, even after I fix my makefile issue, you will still get an 'undefined reference' linker error since it won't be able to find any definitions of the required _malloc_stats_r() function once only newlib-nano is used. In the future I hope to port some of my heap tagging extensions into gcc4mbed. These allow dumping of the heap from within the GDB debugger. You can see used and free locations in the heap and even get the name of the caller who made each allocation. I have had this working in the past for newlib but I need to do some porting as newlib-nano uses a different (simpler) heap structure.

Hello Adam,

Thanks for your answer. I was trying to use this functions to analize the heap memory as you notice. Did you know any other way to do this with the current port?

Regards, Gustavo.

12 Sep 2013

Wim van der Vegt wrote:

Any suggestions how to get past this point?

My guess is that you get this error when you try to compile a .c file. Previously such files were treated as C++. They are now treated as C source code. If you rename the offending file to have a .cpp extension then things might improve.

I hope that helps,

Adam

12 Sep 2013

Gustavo Ojeda wrote:

Did you know any other way to do this with the current port?

This is on my list to look into. I will bump it up in priority and let you know what I discover.

Are you comfortable with using GDB, the GNU Debugger? I have an introduction on how to use GDB with GCC4MBED here. Any solution that I come up with to dump the heap statistics will probably be through the debugger.

If you are using the version of GCC installed by GCC4MBED's install scripts then you can use the following command in GDB to dump the amount of memory currently dedicated to the heap:

printf "heap size=%d\n",**(int**)(_sbrk+28) - ((((int)&Image$$RW_IRAM1$$ZI$$Limit)+7)&~7)

Sorry that it is so ugly. It turns out that there are no symbols for the _sbrk() implementation used by the current GCC4MBED so I have to reach into the _sbrk() machine code to pull out the pointers I want from its literal pool. If you installed a different version of GCC yourself and added it to your PATH then the above trick will not work since the code output will be slightly different.

There can be free chunks within this heap but printed values of heap size will tell you the maximum amount of heap that was required or if it is growing over multiple samples. I don't believe that the heap implementation in newlib-nano will ever decrease this value (the standard newlib implementation would.) So even if you free up everything, you will still see the maximum heap size ever required printed by the above command. However, the heap will be tracking free space with this heap and new allocations will be satisfied from it first before it grows the heap any more.

If you don't mind growing the size of your program, you could also switch back to using the standard newlib library instead. This would allow malloc_stats() to work. You could edit build/gcc4mbed.mk to change this line:

SYS_LIBS = -lstdc++_s -lsupc++_s -lm -lgcc -lc_s -lgcc -lc_s -lnosys

to

SYS_LIBS = -lstdc++ -lsupc++ -lm -lgcc -lc -lgcc -lc -lnosys

I hope that helps,

Adam

You need to log in to post a reply