all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: John Kehayias via Bug reports for GNU Guix <bug-guix@gnu.org>
To: Christopher Rodriguez <yewscion@gmail.com>
Cc: guix-devel@gnu.org, 63267@debbugs.gnu.org
Subject: bug#63267: gcc-toolchain is missing libstdc++.so
Date: Thu, 04 May 2023 17:34:42 +0000	[thread overview]
Message-ID: <87354c11n6.fsf@protonmail.com> (raw)
In-Reply-To: <pkmp4emt2km9nz.fsf@u6908d19b746052.ant.amazon.com>

Hi again,

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

> 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.

> 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

--8<---------------cut here---------------start------------->8---
<some-binary> symbol lookup error: <some-binary>: undefined symbol: _ZNSt18condition_variableD1Ev, version GLIBCXX_3.4.11
--8<---------------cut here---------------end--------------->8---

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

--8<---------------cut here---------------start------------->8---
guix shell -e "(begin (use-modules (gnu packages gcc)) (make-libstdc++ gcc))"
--8<---------------cut here---------------end--------------->8---

I see

--8<---------------cut here---------------start------------->8---
$strings /gnu/store/6897bpw5858bdng744ddqw8rrqjb4frr-libstdc++-11.3.0/lib/libstdc++.so | grep "_ZNSt18condition_variableD1Ev"
--8<---------------cut here---------------end--------------->8---

while for gcc:lib it is defined

--8<---------------cut here---------------start------------->8---
$ strings /gnu/store/l684qgqlrqkbsh8jffp9d8ag6vrpcwgs-gcc-11.3.0-lib/lib/libstdc++.so | grep "_ZNSt18condition_variableD1Ev"
_ZNSt18condition_variableD1Ev
--8<---------------cut here---------------end--------------->8---

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





  parent reply	other threads:[~2023-05-04 17:38 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-04 14:46 gcc-toolchain is missing libstdc++.so Christopher Rodriguez
2023-05-04 15:05 ` Christopher Rodriguez
2023-05-04 15:26   ` bug#63267: " John Kehayias via Bug reports for GNU Guix
2023-05-04 17:33     ` Kaelyn
2023-05-04 18:14       ` Katherine Cox-Buday
2023-05-04 15:23 ` bug#63267: Possible Solution Christopher Rodriguez
2023-05-04 17:34 ` John Kehayias via Bug reports for GNU Guix [this message]
2023-05-09 17:07   ` bug#63267: gcc-toolchain is missing libstdc++.so Simon Tournier
2024-04-17  5:21     ` John Kehayias via Bug reports for GNU Guix
2024-04-22  0:14       ` Simon Tournier
  -- strict thread matches above, loose matches on Subject: below --
2023-05-04 21:50 John Kehayias
2023-05-04 23:45 ` Kaelyn
2023-05-05 20:59   ` John Kehayias
2023-05-05 23:59     ` Kaelyn
2023-05-08  8:41       ` bug#63267: " Josselin Poiret via Bug reports for GNU Guix

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87354c11n6.fsf@protonmail.com \
    --to=bug-guix@gnu.org \
    --cc=63267@debbugs.gnu.org \
    --cc=guix-devel@gnu.org \
    --cc=john.kehayias@protonmail.com \
    --cc=yewscion@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/guix.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.