Richard Biener <rguent...@suse.de> writes:
>> > So then if it succeeds to link to a shared libgcc_s then why
>> > is it not able to find that later? Maybe you miss setting
>> > of a suitable LD_LIBRARY_PATH to pick up the runtime for
>> > your host compiler?
>>
>> For the same reason that we use -static-libstdc++ to avoid this issue
>> for libstdc++.so. I've always considered gcc's tendency to build
>> binaries that don't run by default a major annoyance, all the weasel
>> wording in the FAQ nonwithstanding. I hope to finally do something
>
> True, but if your host compiler builds sth then it's the host
> compiler installs business to make sure it can run ... (and thus
> make the libgcc_s it links to available or only provide a static
> libgcc_s).
Exactly my words. But gcc provides zero help for that. All proposed
workarounds (having every user of gcc set LD_LIBRARY_PATH, messing
around with ldconfig or equivalent, having every single compiler user
provide -rpath/-R on his own) are usability or functionality nightmares
one way or another: the first and second don't scale (imagine a large
site with hundreds of machines and users), and the third imposes work on
the user that the compiler can do best on its own. This may be somewhat
acceptable for single-user/single-system installations of knowledgable
users, but otherwise it's just a bad joke. The compiler has all the
information when/how to pass -rpath/-R and should provide an option to
do so. And if a target has different multilibs, the user suddenly needs
to no not only about $libdir, but about the various multilib (sub)dirs.
Not what I consider user-friendly, and I've seen a large enough share of
somewhat experienced users fail with that.
> For this particular case at least.
>
> Note that I'm not against linking against static libgcc_s for
> lto-plugin. The -static-libstdc++ we use is just because during
> bootstrap picking up the correct libstdc++ was deemed too hard
> to implement and thus the easy way out was -static-libstdc++.
So how should we go forward with this issue? This bootstrap failure is
a regression from all previous releases. As I said, I'd rather not
duplicate the -static-libgcc test from the toplevel, but would do so if
all else fails. Perhaps Paolo could weigh in as the build maintainer?
>> about it for 4.10/5.0 (btw., any word on what the next release is going
>> to be?).
>
> I guess for the simple reason of not breaking scripts we'll go for 5.0
> (and very much hope the libstdc++ ABI issue will solve itself in time).
Yes, that would be amazing.
> I've also suggested to drop the major/minor version difference and
> go with 5.x, 6.x, 7.x releases going forward. We can have a
> bikeshedding BOF at the Cauldron.
This is more than bikeshedding, I believe, because using major versions
this ways suggests larger/incompatible changes to users when there
probably none. And it looses us the ability to signal a real large
change (like an ABI break).
Rainer
--
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University
