cmake "read-only segment has dynamic relocations"

[h0neybadger]

Hello,
I'm working on homebews that requires cmake to compile.
Recently, I'm no longer able to build the project for the switch platform.
( without any changes in the code )

It raises "read-only segment has dynamic relocations" error during the linking process.
I spends countless hours searching without any clues.

I recreated my cmake files from scratch many times. but at the end the result remains the same.
How can I troubleshoot this ( I generated the .map file, but I do no realy know how to read it) ?
Is there a cmake project/example that use excursively the switch's cmake toolchain ?

What are the cmake best practices for devkitpro toolchain ?

We are using portlib, libnx and external (Plutonium) projects as dependencies.
The toolchain seems to change regularly and I really want to provide the most standard config for our projects.

Thank you a lot

[WinterMute]

The problem is we don't actually have any best practices for using cmake with devkitPro toolchains and nobody seems to want to figure out how to do this right. Cmake has what seems like a richly deserved reputation for being a terrible choice for cross-compiling, most especially in an environment that doesn't run on an OS.

The "read-only segment has dynamic relocations" error is due to missing -fPIC/-fPIE options somewhere which should be controlled by CMAKE_POSITION_INDEPENDENT_CODE. You're not supposed to manually specify these flags. https://github.com/devkitPro/pacman-pac ... .cmake#L25 should do the right thing. If it doesn't then either it's in the wrong place or it's being overridden somewhere else.

Right now, as far as I can tell, all the cmake machinery being copied and pasted around every project being built with devkitPro toolchains is massive and ill considered bodgery that needs replacing. I appreciate that people just want to get things working but it really feels like 2 steps forward and 96 steps back as we fix one thing somewhere that breaks all the bodgery and then someone turns up with a sticking plaster that avoids dealing with any of the real issues.

Ultimately, unless your project is intended to be multiplatform from day one we would advise using a stock Makefile template rather than wrestling with cmake.

[h0neybadger]

Thank you a lot WinterMute,
We are using cmake because it's part of the original project.
I'm just providing a switch port.

But each line of your reply remind me painful moments with cmake.
Thank you very much for all your amazing work.

[WinterMute]

The question in this case becomes "What's the best way to add support for devkitPro toolchains to an existing cmake based project?"

A lot depends on how well the existing cmake configuration has been put together and how it expects to find dependencies. This might even require modifying the existing project to improve portability - for instance using FindPkgConfig & pkg_check_modules to find libraries and using fallbacks if that doesn't work rather than creating whole new cmake scripts for individual libraries then carrying those around in every project.

Ultimately the best way to deal with this is to ask for direct help with specific projects rather than looking for general hints that may not be useful in specific cases.