gcc-toolchain is missing libstdc++.so

  • Done
  • quality assurance status badge
Details
6 participants
  • Katherine Cox-Buday
  • Josselin Poiret
  • John Kehayias
  • Kaelyn
  • Christopher Rodriguez
  • Simon Tournier
Owner
unassigned
Submitted by
Christopher Rodriguez
Severity
normal
C
C
Christopher Rodriguez wrote on 4 May 2023 16:46
(address . bug-guix@gnu.org)(address . guix-devel@gnu.org)
pkmp4emt2km9nz.fsf@u6908d19b746052.ant.amazon.com
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!

--
Christopher Rodriguez
() ascii ribbon campaign - against html e-mail
/\ www.asciiribbon.org - against proprietary attachments
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEJMQbvYVxvZ0eF/84XZ6FgaGVz3sFAmRTxpAACgkQXZ6FgaGV
z3sXVw//e4Z8hBFcGSE4l3mZwTHXN3oO4nK1HO8Eh1Ff/Zu+G7ClIPPBFdwBji69
SaPEfDsOYTS/q4BGiOYoTPbYkdZA9O5VEX/wHkXH8Wv1sM8BJinPlTJoFy2XUbId
T8wzeUnwLGbeV0o4cmKk9+cVa3XUsV3S4nV8LrEjt9ML3vSpip98TOf1aqOf3OV8
oTfGm09sKi0Dk3j+9YVHDzCwtlEBg3MqsDvxuxOPHSQ07i5Npez4cudPggcU5rOW
KnGd/9gc9CZ+z65tgT2NKXxtXGRRYTaTcsC/XwKv3ZMjqLj2kkIhABpRWhxQ7l2L
Wa67QXfzRb34CWh0fjaNLSauFxh6iMEppKxwYlnVkokFK8RqownfdYHggWyzxpqs
hjw7/7HiIJ8FGXb78i7QshV7O/ymZfawGuxGsJudVnuPWlSaVYvOW+fpKZe4v4ui
nEDoW91FdMYi6+3Foue/jTawWJQxRkG2By+eBaWkoNNaGOjZs2VhWcOJ8ztuVQOm
gusNMJcmSMHuKTjnMbmhc7+DnYZM2ISd88S0qA0VdHMdG+0i+0ArNSsGY3uWNkl1
MBk/S8F1NvDQZNwH3B0uaBzFoxFTJyLM5A0Sr5jKHoqecLEtSTvLGS66A1BvBxq/
96tIOQIPDNIplzg/Z6Bz8lZ0yQR7tncR/qoY3n9zRgb6+EWINs0=
=G0d/
-----END PGP SIGNATURE-----

C
C
Christopher Rodriguez wrote on 4 May 2023 17:05
(name . Christopher Rodriguez)(address . yewscion@gmail.com)
pkmp4eild8m8z9.fsf@u6908d19b746052.ant.amazon.com
Sorry for the spam; Resending this without the bugs address, but with
the issue's address.

Christopher Rodriguez <yewscion@gmail.com> writes:

Toggle quote (15 lines)
> [[PGP Signed Part:Undecided]]
>
> 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!

--

Christopher Rodriguez
() ascii ribbon campaign - against html e-mail
/\ www.asciiribbon.org - against proprietary attachments
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEJMQbvYVxvZ0eF/84XZ6FgaGVz3sFAmRTygoACgkQXZ6FgaGV
z3vIRhAAgvMQzvhugXdeeWXeKdqOAI0AWwphPBcE0QC3/K0m25yvEikvtualNdx+
v8kjPe2rep5xRO7mCm1YQMbkXRIYlQiZjx2JoyizYnhN/Zf8SQe5e8/iqrvGZwvn
qo8bkYLCO1ynJvv4rzKrvmFZ4dcs7y6s9SjrcJTNwUaKjltEAOWLV5Im4e87LA8G
PZ1v3/RrPgsINeRNn90qJhkv4yYMPAGA35udbvdet/ZMXEjmCnRdrP8inM7lBsTH
LRvnMLbb1PjBUn2XtZdaad2YxtVNp0IADa5ZByYt8bYKoVtUKVb0rnCR9nGNBbAl
4Dt2v9DcaV4Zty4tlezPR3XUZyZeyRdoHqt1boQX1RwlFwIV1/0099DDeKwLbq83
tcynDXoErP/DGfZxhf71TiV1oum7Fbg0oBxIGxThw+Y82AxKvKeolCFxgaAXYrEx
bhUB0wihD+1ySBXhLCxE9TgGALaCsrYhJRAoq/E7A3NO4Dn534z39Ylh4lNuVOuk
9+2F4jH2yBrHQUJMLwTR+IiyDgRWSoiOpUGLZFhpHWUhzhUo+lxK4O5chLJDmQjs
zqWDVYc/vTDiQ7XqG4lqtaLAcPoMdWwgJtS+hbIraXG8fu+w0Zb+3qMT9zo5JK8j
4Tp12JhBNjfHhAc8Xr+5R7ZZL4nOm0sFgbjeqfsMSJz6eugDNGA=
=GXz8
-----END PGP SIGNATURE-----

C
C
Christopher Rodriguez wrote on 4 May 2023 17:23
Possible Solution
(address . 63267@debbugs.gnu.org)
pkmp4ebkj0m84b.fsf@u6908d19b746052.ant.amazon.com
Just spun up a different solution in my personal channel, creating a
package "gcc-unhidden" which inherits from the hidden gcc package and
uses (properties (alist-delete 'hidden? (package-properties gcc))) to
expose it. If the standard use-case—what is expected for most
uses—doesn't require these libraries, maybe it would be better to create
a dedicated package for the edge cases that might need it?



(define-public gcc-unhidden
(package
(inherit gcc)
(name "gcc-unhidden")
(properties (alist-delete 'hidden? (package-properties gcc)))))

--
Christopher Rodriguez
() ascii ribbon campaign - against html e-mail
/\ www.asciiribbon.org - against proprietary attachments
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEJMQbvYVxvZ0eF/84XZ6FgaGVz3sFAmRTzmQACgkQXZ6FgaGV
z3v02BAAu5e1oHMHTqPs4custv+A61m0qsDd/j4JwGyUiIb1T//nEY3Ccmay8f42
uUQpJyEnCDFlDSgqXhh0Hb3AoTQeOHWtzmmWsvTecgutzPaZGZXDWFs0BCT46lQ8
OL7QKNZD0D8FiSNaSBwG5yCKNgno0pEpAWplPkcQQWrnFIDrekoUJWah+ZJNioLY
5Z5+/Ex/v0X/0seZkYc02EWKE31cw1xD/YEnRo6DU0buDHRihVO4uSicP0OSSgg3
r6OGOKrzI3H9OR+TArtyPkDGNa+4pQ0qNydgPiIo/FwUz2ReOO1X/JQPsGbo9IsZ
yRvKW81XpsfwQLjseo3VHhX9fo8VgFOOp82Pu5cMz3R5ZeDaD+wfDHdog41oESk4
L0I4MwKuGht7ZfebT51/uNr4dtFSe5xiIW/LGm89IuYlMKPkqOT8sy1yeOSbWeU6
sGSdGCLbGO6nJuTLeqHHKPdo0do+uSsaW6AUqhHTSBZQ1kOdq4AOWSr+Y/EAFrDF
CZwcQaddFvTcMaLb904QRuNRAomSkLWieQMjbwo+S3lkrb2EGmRYlwxbQqx69sOz
bwRFAfK+4web8ixlKAzn2Z1NjzUXQOCEvaiM/PJ5b0KPxZMcrBWod48JChRTK4vJ
+Ihbvxvy7ovcj7oF5lgO6P1EQtMhw2HibahQgf2ybOh0UuvEuvQ=
=qKAL
-----END PGP SIGNATURE-----

J
J
John Kehayias wrote on 4 May 2023 17:26
Re: gcc-toolchain is missing libstdc++.so
(name . Christopher Rodriguez)(address . yewscion@gmail.com)
874jos15kh.fsf@protonmail.com
Hi Christopher,

On Thu, May 04, 2023 at 11:05 AM, Christopher Rodriguez wrote:
Toggle quote (20 lines)
>
> 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?).

Thanks all!
John
K
K
Kaelyn wrote on 4 May 2023 19:33
(name . John Kehayias)(address . john.kehayias@protonmail.com)
NxF4Z9svIqfZ4ZdSP_LlErXklwpO8siFWZ_aY-KAjK6bfBJ-5xhHJqziFO0pxyQBM4Y79IkCGewvY3Q_2AZETfJ3Rwzrod3OFSwOvm7qov0=@protonmail.com
Hi,

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

Toggle quote (46 lines)
>
> 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
J
J
John Kehayias wrote on 4 May 2023 19:34
(name . Christopher Rodriguez)(address . yewscion@gmail.com)
87354c11n6.fsf@protonmail.com
Hi again,

On Thu, May 04, 2023 at 11:19 AM, John Kehayias wrote:

Toggle quote (7 lines)
> 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 tried locally just adding gcc:lib as an input for gcc-toolchain and
that does the trick. And since it is just a union-build, very quick to
try out :)

guix size reports an increase in gcc-toolchain as 0.1 MiB with gcc:lib
included.

Toggle quote (17 lines)
> 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 tried with my local gcc-toolchain modification and this gets me what
I wanted.

On that note, I forgot to bring up the problem I had with using
make-libstdc++: it does not seem to build the same libstdc++ as
included in the gcc package. The doc string for that procedure notes
that this is meant to be used when using non-gcc toolchains, but we
also have the libstdc++ variable which seems to suggest that
(make-libstdc++ gcc) should be the same library as in gcc.

I'm not sure the difference in looking at the package definitions, but
I don't really know this stuff. Here's an example of the difference I
was finding:

I was running something and it complained that

Toggle snippet (3 lines)
<some-binary> symbol lookup error: <some-binary>: undefined symbol: _ZNSt18condition_variableD1Ev, version GLIBCXX_3.4.11

Indeed, looking at the libstdc++ I used via (or could have used
libstdc++ here directly since I used the default gcc):

Toggle snippet (3 lines)
guix shell -e "(begin (use-modules (gnu packages gcc)) (make-libstdc++ gcc))"

I see

Toggle snippet (3 lines)
$strings /gnu/store/6897bpw5858bdng744ddqw8rrqjb4frr-libstdc++-11.3.0/lib/libstdc++.so | grep "_ZNSt18condition_variableD1Ev"

while for gcc:lib it is defined

Toggle snippet (4 lines)
$ strings /gnu/store/l684qgqlrqkbsh8jffp9d8ag6vrpcwgs-gcc-11.3.0-lib/lib/libstdc++.so | grep "_ZNSt18condition_variableD1Ev"
_ZNSt18condition_variableD1Ev

and using that libstdc++ does not result in that error.

Is make-libstdc++ not meant to be used/mixed with e.g. gcc-toolchain?
Is this expected that it is a different library produced or is this a
bug?

Thanks!
John
K
K
Katherine Cox-Buday wrote on 4 May 2023 20:14
0011bd8c-d32f-bb4b-d1d9-f6539ce20fe9@gmail.com
On 5/4/23 11:33 AM, Kaelyn wrote:

Toggle quote (2 lines)
> 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++.

+1. I recently ran into this as well and went looking for it.

I think a good reason to give libstdc++ its own output is that this
question continually gets asked.

--
Katherine
J
J
John Kehayias wrote on 4 May 2023 23:50
(name . Katherine Cox-Buday)(address . cox.katherine.e@gmail.com)
87sfcbzrzy.fsf@protonmail.com
Hi all,

Toggle quote (11 lines)
> 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...

Nice little hack Kaelyn, would you mind sharing somewhere? I wonder if
this should be something we should have more easily anyway.

On Thu, May 04, 2023 at 12:14 PM, Katherine Cox-Buday wrote:

Toggle quote (13 lines)
> On 5/4/23 11:33 AM, Kaelyn wrote:
>
>> 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++.
>
> +1. I recently ran into this as well and went looking for it.
>
> I think a good reason to give libstdc++ its own output is that this
> question continually gets asked.

That sounds reasonable to me as well. I would think the make-libstdc++
procedure would work for this, but as I detailed in my other message,
I'm not sure why it seems to be missing symbols. We would have just
what we need there and could just expose some public package versions
through that or leave it similar to how it is and document (so it is
more of an advanced or edge case scenario and not have more people
going that way when what they really want is the actual gcc-toolchain
package).

John
K
K
Kaelyn wrote on 5 May 2023 01:45
(name . John Kehayias)(address . john.kehayias@protonmail.com)
Ep1v1JJOnsfi7wG0QvKyBwOVsowFkmpd4B5orgUDEHZzshS6Xnb_nKaokIlcDbD18XvH4n9DVajid9RPnkd_95UtHfMnYRzR57sj6KadoKw=@protonmail.com
------- Original Message -------
On Thursday, May 4th, 2023 at 9:50 PM, John Kehayias <john.kehayias@protonmail.com> wrote:

Toggle quote (15 lines)
> > 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...
>
>
> Nice little hack Kaelyn, would you mind sharing somewhere? I wonder if
> this should be something we should have more easily anyway.

I wasn't sure the best place to share it, so I've attached my "run" script for running the binary download of PolyMC in a container. It is both a shell script and a guix package manifest, and is the one place so far I've worked around the removal of gcc:lib. The main program-specific bits are what CMD defaults to and which packages need to be included (most of the various shares are to get things like hardware 3D, pulseaudio, and dbus working and aren't all always needed). It also contains the original manifest commented-out for comparison. Hope it can be of help to folks!

Cheers,
Kaelyn
Attachment: run
J
J
John Kehayias wrote on 5 May 2023 22:59
(name . Kaelyn)(address . kaelyn.alexi@protonmail.com)
87h6sqze9d.fsf@protonmail.com
Hi Kaelyn,

On Thu, May 04, 2023 at 11:45 PM, Kaelyn wrote:

Toggle quote (12 lines)
> ------- Original Message -------
> I wasn't sure the best place to share it, so I've attached my "run"
> script for running the binary download of PolyMC in a container. It is
> both a shell script and a guix package manifest, and is the one place
> so far I've worked around the removal of gcc:lib. The main
> program-specific bits are what CMD defaults to and which packages need
> to be included (most of the various shares are to get things like
> hardware 3D, pulseaudio, and dbus working and aren't all always
> needed). It also contains the original manifest commented-out for
> comparison. Hope it can be of help to folks!
>

Thanks, that's a nice little hack! Just something very minor I
noticed, but you don't need to specify glibc directly for the -F (FHS)
option in guix shell, as it will automatically include the (modified)
glibc.

This topic came up again on IRC today and GNUtoo had the correct cli
invocation for getting at gcc:lib. I thought I had tried something
similar but must have missed something, or else didn't notice that
this will only work for guix shell, as guix build doesn't take outputs
in the package list:

Toggle snippet (3 lines)
guix shell -e $'(list (@@ (gnu packages gcc) gcc) "lib")'

Thanks to both of you I have some options for workarounds currently,
but based on how this topic keeps coming up I still think we should
have a more straightforward option.

John
K
K
Kaelyn wrote on 6 May 2023 01:59
(name . John Kehayias)(address . john.kehayias@protonmail.com)
1pOI6MV7sx3-zolxwH99rQ93RMcbp677fn9twoyv4ZhNBhicZgnNC4bI_u0-aJCfLOjBDb_q8wmu_JihwNW7ECzh-RUmTn3c4jwfd2BCz-4=@protonmail.com
------- Original Message -------
On Friday, May 5th, 2023 at 8:59 PM, John Kehayias <john.kehayias@protonmail.com> wrote:


Toggle quote (23 lines)
>
>
> Hi Kaelyn,
>
> On Thu, May 04, 2023 at 11:45 PM, Kaelyn wrote:
>
> > ------- Original Message -------
> > I wasn't sure the best place to share it, so I've attached my "run"
> > script for running the binary download of PolyMC in a container. It is
> > both a shell script and a guix package manifest, and is the one place
> > so far I've worked around the removal of gcc:lib. The main
> > program-specific bits are what CMD defaults to and which packages need
> > to be included (most of the various shares are to get things like
> > hardware 3D, pulseaudio, and dbus working and aren't all always
> > needed). It also contains the original manifest commented-out for
> > comparison. Hope it can be of help to folks!
>
>
> Thanks, that's a nice little hack! Just something very minor I
> noticed, but you don't need to specify glibc directly for the -F (FHS)
> option in guix shell, as it will automatically include the (modified)
> glibc.

Thanks! A small side note: I have glibc in there mainly so ldd is available for debugging problems or getting new binaries working (I think the comment with it is a remnant of an older version of the manifest from before "-F" was added to "guix shell").

Cheers,
Kaelyn
J
J
Josselin Poiret wrote on 8 May 2023 10:41
Re: bug#63267: gcc-toolchain is missing libstdc++.so
87r0rr5i6d.fsf@jpoiret.xyz
Hi Kaelyn,

Kaelyn via Bug reports for GNU Guix <bug-guix@gnu.org> writes:

Toggle quote (2 lines)
> Thanks! A small side note: I have glibc in there mainly so ldd is available for debugging problems or getting new binaries working (I think the comment with it is a remnant of an older version of the manifest from before "-F" was added to "guix shell").

Small note: `ldd` is only a wrapper around setting
`LD_TRACE_LOADED_OBJECTS=1`, so you don't really need to pull in all of
glibc just for this. There's also LD_DEBUG with possible values
explained by LD_DEBUG=help, which I use quite often.

Best,
--
Josselin Poiret
-----BEGIN PGP SIGNATURE-----

iQHEBAEBCgAuFiEEOSSM2EHGPMM23K8vUF5AuRYXGooFAmRYtboQHGRldkBqcG9p
cmV0Lnh5egAKCRBQXkC5FhcaipgEDACG+z80EDk2QgDjB2kqtJf8uj1Zj30IKhlt
DZqMrYDpWkPqfdMLrOtS4gk+V/SKHIsf9aAvRBP285bVlGqLKwzmi7CVqldPe7RZ
neX7jzv4HiaLvLOA47v+3l7KtU57tr6pQkWA0QBNBt2HvfBvMsVM3mWGbXCGrctl
tyVKB+MSL7+x/ooaC5r5Hqt5M5p8U/kQlFGa5KBIm3IdzhKpRmBecM8siy4Q1c5o
jLNcEys6+tkPDAFrzODk2JXmEIE4TzGIRBJAFAoMTEUYPcvM5e/yhhV1JOdGumuT
KOm6naU1k0BYLGwoz0gH+3p4VIg6k1CA7a+6Qd/+hQWm1DTeUzXEBSKMOu3u4m2d
7TWvr3tCnvgH7Ji/BINa3tvvGsY8FMp8bvXyrYugI1TSa0CdOEhX/sBVUAkEvRRG
Mx6V1XlSlXz4+eoUNpQyv9CP9azBqLkMj2sTsPhpVrUOKxdkpOYFbmKI12s3Qet1
5OpYGtZl2guPHZURAi4Fb4iegrnVcg0=
=iy4i
-----END PGP SIGNATURE-----

S
S
Simon Tournier wrote on 9 May 2023 19:07
871qjp5t84.fsf@gmail.com
Hi,

I am proposing patch#63393 [1] which adds the output lib to
gcc-toolchain. Well, quoting the comment:

;; The main raison d'être of this "meta-package" is (1) to conveniently
;; install everything that we need, and (2) to make sure ld-wrapper comes
;; before Binutils' ld in the user's profile.

I think, this package gcc-toolchain should be the visible package and
battery included.

WDYT?


Cheers,
simon
J
J
John Kehayias wrote on 17 Apr 07:21 +0200
(name . Simon Tournier)(address . zimon.toutoune@gmail.com)
8734rk36pb.fsf@protonmail.com
Hi everyone,

Apologies for the long delay on this.

On Tue, May 09, 2023 at 07:07 PM, Simon Tournier wrote:

Toggle quote (19 lines)
> Hi,
>
> I am proposing patch#63393 [1] which adds the output lib to
> gcc-toolchain. Well, quoting the comment:
>
> ;; The main raison d'être of this "meta-package" is (1) to conveniently
> ;; install everything that we need, and (2) to make sure ld-wrapper comes
> ;; before Binutils' ld in the user's profile.
>
> I think, this package gcc-toolchain should be the visible package and
> battery included.
>
> WDYT?
>
> 1: https://issues.guix.gnu.org/issue/63393
>
> Cheers,
> simon

I've just pushed, as b47ae1ecc43baaf726701ab2d2f810ecfaa75428, the
patches from that issue (the first from simon, the second my simplified
one just adding gcc:lib to gcc-toolchain).

This should fix the original bug here, so I am closing. However, it was
raised here and in 63393 about alternatives in how we use gcc-toolchain
outputs. As well as the issue I ran into about make-libstdc++.

So, if anyone would like to change anything from the new status quo,
please open a new issue. At least now we are working from a better
default I would say, with gcc-toolchain including the libraries from
gcc:lib.

Thanks all,
John
Closed
S
S
Simon Tournier wrote on 22 Apr 02:14 +0200
(name . John Kehayias)(address . john.kehayias@protonmail.com)
87jzkq6yoo.fsf@gmail.com
Hi,

On mer., 17 avril 2024 at 05:21, John Kehayias via Bug reports for GNU Guix <bug-guix@gnu.org> wrote:

Toggle quote (2 lines)
> I've just pushed, as b47ae1ecc43baaf726701ab2d2f810ecfaa75428,

Cool! Thank you for crossing the finish line.

Cheers,
simon
Closed
?
Your comment

This issue is archived.

To comment on this conversation send an email to 63267@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 63267
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch