Arduino IDE 1.5.2 platform.txt file. recipe.c.combine.pattern contains "{build.path}/syscalls_sam3.c.o" and {object_files}.

[jantje]

Hi
I'm currently working on porting my arduino eclipse plugin to Arduino IDE 1.5.2. I first would like to say I like the idea of having the configuration in an external file so it allows for a great deal of flexibility and can be reused by other tools.
When working with it however I have some questions/doubts for which I hope this is the forum to discuss. (the google forum is dead :-( ; and the old mailing list doesn't work any more for me)
My biggest question right now is about
recipe.c.combine.pattern="{compiler.path}{compiler.c.elf.cmd}" {compiler.c.elf.flags} -mcpu={build.mcu} "-T{build.variant.path}/{build.ldscript}" "-Wl,-Map,{build.path}/{build.project_name}.map" -o "{build.path}/{build.project_name}.elf" "-L{build.path}" -lm -lgcc -mthumb -Wl,--cref -Wl,--check-sections -Wl,--gc-sections -Wl,--entry=Reset_Handler -Wl,--unresolved-symbols=report-all -Wl,--warn-common -Wl,--warn-section-align -Wl,--warn-unresolved-symbols -Wl,--start-group "{build.path}/syscalls_sam3.c.o" {object_files} "{build.variant.path}/{build.variant_system_lib}" "{build.path}/{archive_file}" -Wl,--end-group

This patters contains "{build.path}/syscalls_sam3.c.o" and {object_files}
There are 2 problems I have with that.

1. {object_files} should contain "syscalls_sam3.c.o" so this is redundant information
2. "{build.path}/syscalls_sam3.c.o" is semi hard coded. In my case the file is "{build.path}/arduino/syscalls_sam3.c.o" but some tools may even prefer not to have the .c.o format. So eclipse complains about not finding the file.

So my question is : could "{build.path}/syscalls_sam3.c.o" be removed?

Best regards
Jantje

[cmaglie]

hi @jantje,
the fix was introduced here:

e43dcd8

the original problem was that the syscalls_sam3.c.o object was discarded by the linker for some unknown reasons. This lead to build fails while using malloc() for example. If we put the file in the linking group it gets linked correctly.

This is a ""temporary"" workaround, we must figure out why gcc fails to link against it from core.a since theoretically it should work.

C

[jantje]

C
Thanks for the response :-)
I'm happy to hear this is only a workaround.
In my eclipse plugin I am using all the arduino tools and the commands as described in the platform.txt. I do not have this GCC fail. Maybe this can help you identify the root cause?

on the platform.txt subject:
Why is tools.bossac.upload.pattern defined as "{path}/{cmd}" ....and not as "{tools.bossac.path}/{tools.bossac.cmd}" ..... ?
And the same for tools.avrdude.bootloader.pattern being defined as "{cmd.path}" "-C{config.path}" .... and not "{tools.avrdude.cmd.path}" "-C{tools.avrdude.config.path}"
I ask because I see no benefit and some extra code is needed to expand the tag.
Best regards
Jantje

[avikde]

I just ran into this issue (g++ not linking properly from core.a) and found a better solution: the "--whole-archive" linker option ensures that all the object files are linked, not just the parts that g++ thinks are needed. This is the relevant part of my recipe.c.combine.pattern

-Wl,-whole-archive "{build.variant.path}/{build.variant_system_lib}" "{build.path}/{archive_file}" -Wl,-no-whole-archive

Credit for the solution goes to this thread http://stackoverflow.com/questions/953020/using-ar-to-combine-o-and-a-files-linux

[matthijskooijman]

Using whole-archive breaks the 'include ISRs only when needed' trick we use for HardwareSerial on AVR (and might want to use on SAM as well in the future). See #1711 (comment)

As for the original problem, I'm not sure how that file is supposed to work. It only defines functions like _write, wheras I would expect them to be referenced as write. Or perhaps these functions are never referenced directly from user code, only from libc functions (e.g. I can imagine that malloc would reference _sbrk. If so, then the question is why gcc doesn't add these symbols to the "symbols I still need to resolve" list when linking. Perhaps libc provides its own weak implementations of these functions?

Perhaps a workaround could be to add an empty function pullin_syscalls() to that .c file and then call that function from main() to force pulling in the object? Not very pretty, but I'd expect this to work (and it's less ugly than the current approach).

[jantje]

This has been fixed a long time ago