Build fails on K64F with Eclipse

[CarloMara]

Little Info

• Type: Bug
• Priority: Major

Target
K64F

Toolchain:
GCC_ARM

Toolchain version:
4_9-2015q3

mbed-cli version:
1.0.0

Expected behavior
After exporting the project to eclipse using gnuarmeclipse exporter, the project should get build.

Actual behavior
The build fails with:

mbed-os/targets/TARGET_Freescale/TARGET_MCUXpresso_MCUS/TARGET_MCU_K64F/device/TOOLCHAIN_GCC_ARM/MK64FN1M0xxx12.ld:66: ignoring invalid character '#' in expression

mbed-os/targets/TARGET_Freescale/TARGET_MCUXpresso_MCUS/TARGET_MCU_K64F/device/TOOLCHAIN_GCC_ARM/MK64FN1M0xxx12.ld:66: syntax error

Steps to reproduce
Exports blink project with mbed export -m K64F -i gnuarmeclipse, open eclipse, import the project, ant try to build it.

[bulislaw]

I was having issues with another board #3919

[bulislaw]

@theotherjimmy

[CarloMara]

@bulislaw I can also confirm that the build works if compiled with mbed-CLI. FYI same toolchain of eclipse.

Cheers,
Carlo

[ilg-ul]

I'm afraid this is a misunderstanding, this file is not a linker script file, but it requires non-standard preprocessing, and this cannot work in Eclipse

https://github.com/ARMmbed/mbed-os/blob/master/targets/TARGET_Freescale/TARGET_MCUXpresso_MCUS/TARGET_MCU_K64F/device/TOOLCHAIN_GCC_ARM/MK64FN1M0xxx12.ld

[theotherjimmy]

So, the interesting thing here is that pre-procesing is standard on ARMLink scatter files, and IAR whatever their link file is called. We added it to GCC for feature parody.

@ilg-ul Do you think that adding a make rule to the makefile.targets file to run the linker script through the preprocessor would be enough to make gnuarmeclipse pre-process it's linker scirpts?

[ilg-ul]

added it to GCC for feature parody

and parody you got. totally unusual for GCC linker files. bad idea.

a make rule to the makefile.targets file

and what would the extra rule do? convert from the un-preprocessed MK64FN1M0xxx12.ld to a processed MK64FN1M0xxx12.ld?

the major problem I see with this issue is not the need to somehow process a file before the build, this can be accommodated somehow, but the decision to masquerade the file as .ld, given the fact that the GNU linker is not able to run it through the preprocessor.

I do not know how you process these linker scripts in the makefile version of the build; if you have a functional solution there, try to clone it here.

if not, my suggestion is to rename the input file to something else but .ld and then you can add any rules you need.

but please be aware that due to the famous poor make support for file names with spaces, the rule must be executed in the folder where the file to process it located, to avoid the need to enter full paths in the rules.

as a conclusion, I'm no longer very confident that mbed is generic/portable enough for a reliable exporter. :-(

[theotherjimmy]

and what would the extra rule do? convert from the un-preprocessed MK64FN1M0xxx12.ld to a processed MK64FN1M0xxx12.ld?

It would process MK64FN1M0xxx12.ld to some post-processed-link-script.ld or something. That's what the makefile solution does.

but the decision to masquerade the file as .ld

Honestly, no decision was made there, we just modified the files in place. I understand that is implicitly a decision, but I'm just saying that we clearly made a bad decision by not making a decision.

if not, my suggestion is to rename the input file to something else but .ld and then you can add any rules you need.

Definitely a good idea. We can rename the files to something else. .ldp comes to mind as ld + preprocessor. I'm open to suggestions for extensions.

as a conclusion, I'm no longer very confident that mbed is generic/portable enough for a reliable exporter. :-(

One little preprocessing bit, and it's not portable. You're right though. I will give you that it's not portable because GCC does not normally pre-process it's linker files.

[theotherjimmy]

See PR #4069

[theotherjimmy]

#4069 was merged, is this still an issue?

[theotherjimmy]

No response. Closing. Please re-open if it's still a problem.