Build libstdc++ as a module

[keith-packard]

Provide a mechanism to build libstdc++ as a module, instead of requiring that it be included in the toolchain.

[zephyrbot]

The following west manifest projects have changed revision in this Pull Request:

Name	Old Revision	New Revision	Diff
libstdcxx 🆕	N/A (Added)	keith-packard/libstdcxx-module@9ac70a1 (main)	N/A

⛔ DNM label due to: 1 added project

Note: This message is automatically posted and updated by the Manifest GitHub Action.

[keith-packard]

Ok, I spent some quality time updating this PR, rebasing and then cleaning it up so that you can configure the version of GCC used to build the module.

To finish this off, we'll need a new repo in zephyrproject-rtos to hold the module itself. That doesn't include the gcc source code, that is pulled out of the SDK repository during the build process. Probably 'module-libstdc++' or some such would be fine. I don't have permission to create that, so help is needed here.

[keith-packard]

I think this would probably be a better plan than zephyrproject-rtos/sdk-ng#863 as this wouldn't involve building libstd++ in two ways for every possible SDK target.

[adigie]

I tried this module approach and it worked fine, however it doubled the compile time for our sample (which is long by itself):

It may have some use cases, but I think having pre-compiled version without exceptions (which probably would be most of the cases) would be nice. Using module would not work for us, as this would significantly increase build times, slow down CI pipeline and local development.

By the way, I compared the binaries (module and noexept from this build) with

bloaty --domain=vm module.elf -- noexcept.elf -d sections,compileunits,symbols -n 0

and it looks like module version is slightly bigger. Do you know what might be the difference?

bloaty output: bloaty.txt

[keith-packard]

I tried this module approach and it worked fine, however it doubled the compile time for our sample (which is long by itself):

It may have some use cases, but I think having pre-compiled version without exceptions (which probably would be most of the cases) would be nice. Using module would not work for us, as this would significantly increase build times, slow down CI pipeline and local development.

If you think most people would disable exceptions, then perhaps the SDK should ship that way. Now that there's an option to build as a module, the few cases wanting exceptions could use that. The cost of including two libstdc++ versions in the sdk is considerable and weighs on every single Zephyr user, even those not using C++ at all.

and it looks like module version is slightly bigger. Do you know what might be the difference?

Presumably configuration and compiler options. The module uses the zephyr-specific cmake support in picolibc, so it doesn't get as much testing or use.

You might compare the generated picolibc.h files to see which options are selected in both cases? And compare the compiler options used?

[adigie]

If you think most people would disable exceptions, then perhaps the SDK should ship that way. Now that there's an option to build as a module, the few cases wanting exceptions could use that. The cost of including two libstdc++ versions in the sdk is considerable and weighs on every single Zephyr user, even those not using C++ at all.

I asked about this on Discord.

Presumably configuration and compiler options. The module uses the zephyr-specific cmake support in picolibc, so it doesn't get as much testing or use.

You might compare the generated picolibc.h files to see which options are selected in both cases? And compare the compiler options used?

Will check, thanks!

[aescolar]

@keith-packard given that Zephyr is Apache 2, and this new module is new code, I guess it would need to be also Apache2 licensed, and not BSD3.
(by the way, I do not think you can claim copyright in your name on the license file itself :) )

[aescolar]

@keith-packard I'm not opposed to having something akin to this. But when we started discussing building this library from source a few months ago, my hope was we could build it also for the native_simulator based targets (just like we can with picolibc), which with this current solution we can't.
Would it be possible to support this usecase?

Anyhow, a comment on the approach itself: Downloading ~130MB for each image build is probably not something people will be too happy about and feels a bit extreme.

[keith-packard]

@keith-packard I'm not opposed to having something akin to this. But when we started discussing building this library from source a few months ago, my hope was we could build it also for the native_simulator based targets (just like we can with picolibc), which with this current solution we can't. Would it be possible to support this usecase?

It should work with the native simulator with picolibc; libstdc++ has libc-specific code, which is why there are limitations in the config bits. I'm not sure why it isn't working with native_sim, but can check.

Anyhow, a comment on the approach itself: Downloading ~130MB for each image build is probably not something people will be too happy about and feels a bit extreme.

Yeah, it would be easy to just dump the gcc source into the module repo. However, that's all GPL licensed, which seemed like it would conflict with Zephyr policy.

[keith-packard]

@keith-packard given that Zephyr is Apache 2, and this new module is new code, I guess it would need to be also Apache2 licensed, and not BSD3. (by the way, I do not think you can claim copyright in your name on the license file itself :) )

I can easily change the license, but BSD3 is apache2 compatible and there is lots of that in other modules?

[aescolar]

@keith-packard

I'm not sure why it isn't working with native_sim, but can check

That'd be nice

[keith-packard]

That'd be nice

Yeah, gcc doesn't like this mode at all -- we're using the native compiler to build things, so it doesn't believe we're cross-compiling. I'm not sure that will be easy to fix, gcc's build system is somewhat arcane.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud