OS can break the compilation

[javier-moreno-tridonic-com]

Trying to resolve this issue and thanks to @hasnainvirk we saw that when compiling some examples, the #include directives resolution has different behaviours in linux and windows. This is mainly caused by names that will be considered as different by linux and not by windows.

For instance the file thread.h that is part of the sal-stack-nanostack-private source and Thread.h included in mbed-os source.

@MarceloSalazar @markus-becker-tridonic-com

[MarceloSalazar]

@screamerbg @sg- can you look into this please?

[sg-]

Thanks for the note. Need to update the includes client and rf driver use. Will resolve this @geky

[ciarmcom]

ARM Internal Ref: IOTMORF-426

[geky]

The client has had conflicting header files removed for a while, but it unfortunately took a while to move into mainstream mbed-os.

I'm unfamiliar with the rf driver and it my have been removed in a previous change. Do the includes still present issues?

[javier-moreno-tridonic-com]

I tried a fresh checkout of mbed-os-example-client and v5.0.5 of sal-stack-nanostack-private

Builds, but linking fails.

Link: mbed-os
../.build/NUCLEO_F401RE/GCC_ARM/hal/common/retarget.o: In function __wrap_main': retarget.cpp:(.text.__wrap_main+0xe): undefined reference tomain'
collect2.exe: error: ld returned 1 exit status
[ERROR] ../.build/NUCLEO_F401RE/GCC_ARM/hal/common/retarget.o: In function __wrap_main': retarget.cpp:(.text.__wrap_main+0xe): undefined reference tomain'
collect2.exe: error: ld returned 1 exit status

[mbed] ERROR: "python" returned error code 1.
[mbed] ERROR: Command "python -u C:\Code\sandbox\nanostacktest\mbed-os-example-client\mbed-os\tools\make.py -t GCC_ARM -m NUCLEO_F401RE --source .. --build ...build\NUCLEO_F401RE\GCC_ARM" in "C:\Code\sandbox\nanostacktest\mbed-os-example-client\mbed-os\features"

[hasnainvirk]

@geky The issue is still valid. The problem does not arise if you are using Nanostack binaries with public release. However, if you are using sources file name conflict will arise in Windows OS. Because Windows is case insensitive. Javier explained it very well above.

We changed the atmel-rf-driver to include rots.h instead of Thread.h, Mutex.h and namespace mbed.
The real thing here is that the mbedOS tries to link files alphabetically, so whichever Thread.h or thread.h comes first , gets compiled. And then creates nuisance for others.

[sg-]

This shouldn't be the case. mbed.h (rtos.h included by mbed.h) is the entry point and should use path referenced includes. If this is not the case, please open an issue for that. Its not clear here what you're saying the problem is.

[hasnainvirk]

@kjbracey-arm Can you please explain here what we saw while compiling with Nanostack sources ?
I tried to explain in this comment #2411 (comment) what I understood. If you have a better explanantion, please provide.

[sg-]

@javier-moreno-tridonic-com it sounds like the main function is missing. The original issue is confirmed to be resolved. If there is a different issue, please open it with steps to reproduce.