CMake port: linking errors

[zaninime]

I tried porting the whole build system on CMake, it goes all well until the final linking phase where I get this error from collect2. If I can fix this then I'll obviously do a PR. ;-)

Tell me if you need smth else. I'm available for testing.

../core/libcore.a(exception_vectors.S.obj): In function `LoadStoreErrorHandler':
(.vecbase.text+0x78): dangerous relocation: l32r: literal placed after use: .vecbase.literal
../core/libcore.a(exception_vectors.S.obj): In function `LoadStoreErrorHandler':
(.vecbase.text+0x95): dangerous relocation: l32r: literal placed after use: (.vecbase.literal+0x4)
../core/libcore.a(exception_vectors.S.obj): In function `LoadStoreErrorHandler':
(.vecbase.text+0xdc): dangerous relocation: l32r: literal placed after use: (.vecbase.literal+0x8)
../core/libcore.a(exception_vectors.S.obj): In function `LoadStoreErrorHandler':
(.vecbase.text+0xec): dangerous relocation: l32r: literal placed after use: (.vecbase.literal+0xc)
../core/libcore.a(exception_vectors.S.obj): In function `LoadStoreErrorHandler':
(.vecbase.text+0x10b): dangerous relocation: l32r: literal placed after use: (.vecbase.literal+0x10)
../core/libcore.a(exception_vectors.S.obj): In function `call_user_start':
(.vecbase.text+0x1e8): dangerous relocation: l32r: literal placed after use: (.vecbase.literal+0x14)
../core/libcore.a(exception_vectors.S.obj): In function `NMIExceptionHandler':
(.vecbase.text+0x203): dangerous relocation: l32r: literal placed after use: (.vecbase.literal+0x18)
../core/libcore.a(exception_vectors.S.obj): In function `NMIExceptionHandler':
(.vecbase.text+0x23d): dangerous relocation: l32r: literal placed after use: (.vecbase.literal+0x1c)
../core/libcore.a(exception_vectors.S.obj): In function `NMIExceptionHandler':
(.vecbase.text+0x240): dangerous relocation: l32r: literal placed after use: (.vecbase.literal+0x20)
../core/libcore.a(exception_vectors.S.obj): In function `NMIExceptionHandler':
(.vecbase.text+0x248): dangerous relocation: l32r: literal placed after use: (.vecbase.literal+0x24)
../core/libcore.a(exception_vectors.S.obj): In function `NMIExceptionHandler':
(.vecbase.text+0x24d): dangerous relocation: l32r: literal placed after use: (.vecbase.literal+0x28)
../core/libcore.a(exception_vectors.S.obj): In function `NMIExceptionHandler':
(.vecbase.text+0x286): dangerous relocation: l32r: literal placed after use: (.vecbase.literal+0x2c)
../core/libcore.a(exception_vectors.S.obj): In function `.NMIFatalStackOverflow':
(.vecbase.text+0x299): dangerous relocation: l32r: literal placed after use: (.vecbase.literal+0x30)
../core/libcore.a(exception_vectors.S.obj): In function `UserExceptionHandler':
(.vecbase.text+0x2bd): dangerous relocation: l32r: literal placed after use: (.vecbase.literal+0x34)
../core/libcore.a(exception_vectors.S.obj): In function `UserExceptionHandler':
(.vecbase.text+0x2dd): dangerous relocation: l32r: literal placed after use: (.vecbase.literal+0x38)
../core/libcore.a(exception_vectors.S.obj): In function `NMIExceptionHandler':
(.vecbase.text+0x245): dangerous relocation: call0: call target out of range: sdk_wDev_ProcessFiq
../core/libcore.a(exception_vectors.S.obj): In function `UserExceptionHandler':
(.vecbase.text+0x2c3): dangerous relocation: call0: call target out of range: sdk__xt_int_enter
../core/libcore.a(exception_vectors.S.obj): In function `UserExceptionHandler':
(.vecbase.text+0x2e9): dangerous relocation: call0: call target out of range: sdk__xt_int_exit
collect2: error: ld returned 1 exit status

[projectgus]

Hi @zaninime,

Sounds interesting! I believe you're seeing these link errors because of compiling without -mtext-section-literals - the literals are placed in a different section, then end up out of range at link time.

You probably also want -mlongcalls if it's not already in your compiler flags.

Look forward to seeing how cmake shapes up. FWIW there's some (fairly rambling) discussion in #28 about how we'd like to direct the build process long-term, aiming for a two stage process.

[foogod]

I am a bit curious as to what using CMake would really get us here.. It is true that the current makefiles are a bit less-than-ideal (and arguably unnecessarily complicated in spots), but I'm not at all sure that using CMake would be an improvement..

In my experience, CMake is most useful for projects which need to build across a variety of different platforms (which will never be the case for us), or which have a lot of dependencies on other libraries/components (we don't), or have a lot of configurable/optional pieces (which we don't really either). On the other hand, it adds a (not insubstantial) extra build requirement, and a lot of extra learning curve for anybody who wants to use esp-open-rtos for anything..

Admittedly, I may be missing something..

[projectgus]

I guess I was curious to see it, but I also would have some reservations about replacing Make unless there were obvious big benefits - so far the build requirements for esp-open-rtos have been kept as minimal as possible very intentionally.

Still interested to see it though. In particular, if it's significantly simpler then I'd consider that it could be an option for a separated library build - where we can say "you don't need cmake/etc to build the library, you can just do XYZ and use any build system you like. but if you want to rebuild the libraries, install these extra dependencies."

[zaninime]

Unfortunately I'm still away from my computer so I can't give you examples and/or code. The fact is that I've set all the CFLAGS and CXXFLAGS to mimic the Makefile's build system.

I also made sure that I was linking to the rtos libc etc. by using the -Wl,--verbose switch and comparing the output.

I will upload everything on GitHub ASAP :)

[zaninime]

Here's the build log -- if you can spot anything... http://sprunge.us/VEHf

Here's my work (WIP): https://github.com/zaninime/esp-open-rtos/tree/develop

[projectgus]

I missed that the problem was with an object from an assembly source rather than C/C++.

There was a "bug" in the makefile where C_CXX_FLAGS was applied to all sources - C, C++ and assembly. The assembler needs to see -mtext-section-literals otherwise you get the exact linking error that you saw.

I've rewritten the Makefile a bit so there's a common CPPFLAGS that goes to all 3, with these options. That should make it clear what you'd need to change for cmake to work as well.

Looking at your branch at a glance, the cmake source does seem somewhat more structured than the Makefiles. I don't know if it's something I'd want to change while the build system reamins as-is, but I'd be keen to at least discuss using it for library builds once we have a separate library/program structure.

[zaninime]

Thank you @projectgus. I fixed it. Should I do a PR?

[zaninime]

@projectgus: I got the executable linking correctly. I still have some problems with it. It seems that by generating the same example (ie. blink, cpp_01_tasks) using the Makefile system and CMake there are some differences in the bin files (non OTA mode).

In fact the bin file flashed at 0x00000 is only 20K (CMake) while the working one (Makefile) is 38K.
The other one, the one at 0x20000 is 191K (CMake) and 173K (Makefile).

Some simple maths tells me that (191-173 = 18) and (38 - 20 = 18), in other words it seems that some stuff gets allocated in the SPI flash insted of the iram.

By loading the files generated from my CMake system I just get some random chars as the serial output.

Here's the map file from CMake, using blink.c as the source file. http://sprunge.us/HNWD

Any hints?
Thanks a lot for your help.

[zaninime]

Found it - zaninime@2005f92#diff-575467a87cbb0305939a854a90321cdaL102

now it's complete!