I’m trying to follow the instructions to setup the toolchain and running ./scripts/build-plugin-libc-autotools.sh 14 /usr/bin/
However this does not correctly setup the include path and I get grep: /include/newlib.h: No such file or directory which should be /usr/lib/arm-none-eabi/include/newlib.h
Does anyone have better instructions for how to setup the correct plugin-libc ?
Hmm, I think the issue is that`-print-sysroot` returns empty, which then cascades to the rest of the script.
Are you using your distro’s package manager’s version of arm-gcc? Or did you install the official arm toolchain into your /usr/bin dir?
The distro package of course 
Or is this not supported?
It’s probably possible to use, but not supported in this case. You’ll want to get the toolchain from arm - https://gitlab.arm.com/tooling/gnu-toolchains-for-arm
Then you extract the toolchain and put it wherever you want it to live. I tend to do ~/.gcc/arm-none-eabi/. It’s also common to put downloaded binaries into /opt
Then you’ll need to put the toolchain’s bin directory on your PATH and the script should work after that.
Also you shouldn’t even need to build the library if you download the latest arm toolchain (15.3)
You also probably want to remove the Debian distributed toolchain so it doesn’t resolve first in your PATH
I usually override my PATH with the downloaded GCC path.
Will try with the latest 15.3 in a bit, thnx!
Ok I think I’m getting somewhere. Have a basic test plugin built.
Now on to the next steps
So in the future I’ll just download a specific arm toolchain and point to that, rather than rely on any distro built in tools (although it has served my perfectly for any of my cross-compile needs over the years).
I can try to figure out why a distro-installed toolchain won’t work. The plugin-libc script was made primarily for us to generate the bundled plugin libc.a archives that we distribute in the SDK for building plugins against. So, all it was tested it for was doing a clean download of the various versions of the toolchain, building the plugin libc, and then making sure plugins built with those would work.
This is a different type of build than typical cross-compiling, because normally you build an .elf or binary file against the libc that’s bundled in the toolchain (whether it’s installed by the distro or from a download). There are lots of *.a files included with the arm toolchain buried in its directories, and when you build normally, it links with those object archive files.
In the case of the MetaModule, plugins are dynamically loaded objects so they need to be build with certain flags that enable the dynamic relocations to be built into them. However, neither arm nor any distro I’m aware of ships .a files that were built with dynamic relocations. Therefore we have to build our own .a libraries from scratch. And they’re very closely coupled to the compiler version, so there’s a different one for v12, v13, etc.
Doing all this is an extra step and adds complexity to the build, but it lets us have the dynamic plugin loading feature that makes the MetaModule an open platform.
Ok, I went at this a bit, but with arm gcc 13 on Debian. You’re right that -print-sysroot is empty for this distro build, but that’s easy enough to work around by getting the #include path.
But — that’s not the only issue. It turns out the getentropy symbol is not defined in this distro configuration, but is defined in the arm gnu release. There are several other symbols missing, as well, but this is the only one that I’ve yet seen come up in a plugin. getentropy is required for std::random_device and would make a handful of plugins break since the SDK does not provide this symbol.
So, long story short – it’s still recommended to use the ARM GNU releases, but the script will now make an attempt to use a distro version and tell you to use the ARM GNU release if it finds those symbols missing
Debian 13 has arm-none-eabi-gcc (15:14.2.rel1-1) 14.2.1 20241119 btw
But good to know. I’ll just point to a local arm-gcc 15.3 for now.