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.

[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

[github-actions]

This pull request has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this pull request will automatically be closed in 14 days. Note, that you can always re-open a closed pull request at any time.

[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

[sidmodi-nexera]

@keith-packard I'm trying to use Picolibc for native_sim with my C++ project and am having some issues - any word on whether this PR will be moving forward? Thanks!

[keith-packard]

@keith-packard I'm trying to use Picolibc for native_sim with my C++ project and am having some issues - any word on whether this PR will be moving forward? Thanks!

To make it work with native_sim would involve fixing the build system for the underlying gcc repository; if you're up for a challenge, I'd be happy to review changes, but I don't have any need for this now that the Zephyr SDK will include two versions built with and without exception support.