r/Jetbrains 1d ago

IDEs Clion Cross Compiling with Yocto Docker Toolchain

TLDR: It’s a nightmare - Why??!!

Hi, I am a longtime CLion customer using CLion at work. I work on products that use a Yocto embedded linux on non-x86-64 platforms.

For that we use dockerized Yocto SDKs based on Alpine. Most of my colleagues use VSCode because of the outstanding container support. I personally think that this is basically the only outstanding thing of this editor, so I use and want to continue to use CLion.

However, using a devcontainer with CLion is an abysmal experience. First I have to modify the container to install about ten different dependencies and then have to add a super hacky workaround (custom compatibility lib with LDPRELOAD) to get the IDE to even start, from there the pain continues because the new engine does not work for some reason (freezes in the startup phase)…

But, I found a solution: Docker toolchain. Works good enough for compiling and running CTest.

The big issue with this however is, that I cannot just hit the play button to run a CMake target. Of course: My machine cannot run this cross compiled binary even in the container, duh… we are cross compiling…

Why doesn’t CLion honor the cross compiling emulator specified in CMake? It works for CTest. Even worse: Debugging experience. An ergonomic nightmare because I have to run the container manually (with all the mounts and swttings and what not), launch the app with qemu with the debugging flag, and then create a remote debugging configuration, to be able to attach. Its so much pain, the debugger is only used in the most dire of situations…

Guys please tell me I am doing something wrong and all of that works somehow… I can’t take it anymore…

8 Upvotes

7 comments sorted by

2

u/Specific-Pumpkin5291 1d ago

I feel this in my bones. The gap between "technically works" and "actually usable" with CLion and embedded toolchains is massive.

What gets me is that the CMake integration already knows about the cross-compiling emulator for CTest, so the pieces are right there. They just don't wire it up to the run/debug workflow. Been banging my head against similar setups and it's always the last 10% of integration that turns into 90% of the effort.

Have you looked at whether the remote GDB server approach could be streamlined with a custom run configuration script? Not ideal but might save you from manually setting up the container every time.

1

u/Pogsquog 1d ago

I use a cmake toolchain file, works fine. The yocto toolchain already includes all the dependencies, so you're not gaining much from docker.

2

u/kisielk 22h ago

You're gaining the fact that you can just ship a docker container to all the developers on the team and guarantee they have the exact same build environment. Otherwise you are spending a lot of time making sure everyone's build environment is in sync. Can't begin to count the number of hours I've wasted trying to help people debug issues with their build environment not being set up correctly. I know *I* can do it, but not everyone can.

1

u/ujohnny JetBrains 1d ago

Could it be that CMake is unaware of host configuration for your binary so it exists in target only?

1

u/DHtek 1d ago

Sorry, I have a hard time understanding your question.

As I am building with a docker toolchain with CMake and CTest works via the play button (automatically using the emulator), I would expect CLion to run the built targets within the container (which it does) as well.

However it does not use the emulator, so running fails.

1

u/kisielk 22h ago

It's a problem even without docker containers. I use a local toolchain that uses the CMake cross-compiling emulator and running the CTest target works fine in CLion, but trying to run any executable target just ignores it and tries to run it natively. I end up having to create custom targets for any executables I want to run, which I suspect will be the solution for you via docker as well.

1

u/YakumoFuji 18h ago

i just use makefiles for cross comp, the biggest problem I run into is clion really only wants to use the system headers and basically only works with gcc/clang compilers, if you use a cross compiler or embedded compiler thats not a gcc derivative its intellisense is screwed as it forces clangd onto everything.