Re: gcc-toolchain is missing libstdc++.so

[Kaelyn <kaelyn.alexi@protonmail.com>]

Hi,

------- Original Message -------
On Thursday, May 4th, 2023 at 3:26 PM, John Kehayias <john.kehayias@protonmail.com> wrote:

> 
> Hi Christopher,
> 
> On Thu, May 04, 2023 at 11:05 AM, Christopher Rodriguez wrote:
> 
> > Sorry for the spam; Resending this without the bugs address, but with
> > the issue's address.
> > 
> > Christopher Rodriguez yewscion@gmail.com writes:
> > 
> > > Hello All,
> > > 
> > > I noticed today that libstdc++.so.1 (and some others), which used to be
> > > part of gcc:lib, are not included in any of the outputs of the
> > > superceding `gcc-toolchain` package.
> > > 
> > > Is there another method for getting these needed shared libraries in a
> > > guix system at this point? It's entirely possible I'm missing something.
> > > 
> > > I am CCing guix-devel@gnu.org per podiki[m]'s request.
> > > 
> > > Thanks!
> 
> 
> Thanks for opening this and cc'ing; this has come up with some
> frequency on IRC, especially recently. In discussing there today, the
> current reasoning is that usually one will just call g++ which knows
> how to find libstdc++. So, gcc-toolchain does not include gcc:lib as
> part of what it makes available.
> 
> I think what we (and when this comes up, others) are getting at are
> some edge cases or different use cases where one wants to directly get
> at libstdc++. Previously it was more direct to use gcc:lib; of course
> one still can in code and/or cli with the proper call. For example,
> guix build -e "(@@ (gnu packages gcc) gcc)" will download/build/show
> the lib output of the (hidden) gcc package. Though I'm not sure how to
> select just the lib output here.
> 
> My use case currently is in the FHS container where a binary wants to
> find some libraries directly. Previously one would include the gcc:lib
> package output in the guix shell call. Now some of those libraries can
> be found elsewhere, like libgccjit, but libstdc++ seems to be the
> trickier one. Open to other suggestions/workarounds, or thoughts on if
> it is worthwhile to include gcc:lib in the gcc-toolchain package (or
> make a gcc-toolchain:lib output?).

I have similar use cases of FHS containers to run binaries (primarily games). I recently ran into the issue of gcc:lib going away and no output from a visible package providing libstdc++. My current workaround was to implement a replacement for specifications->manifest that could handle packages and '(package "output") pairs in addition to strings, so that I could include `(,(@@ (gnu packages gcc) gcc) "lib") in place of "gcc:lib". Internally it resolves package strings to packages with specification->package, then passes the package and optional output specifier to package->manifest-entry. But I digress a little...

Regarding solutions, I would prefer to have libstdc++ in it's own package or output rather than bundled into gcc-toolchain:out; it feels messy and against the grain of isolating programs in containers if I have to make the gcc and g++ compilers available in the container in order to run a program that needs libstdc++.

Cheers,
Kaelyn