[PATCH 2/3] Define libgcc soname in make scripts and not in a header

[Carlos O'Donell]

On Thu, Apr 12, 2012 at 12:30 PM, Roland McGrath <roland@hack.frob.com> wrote:
> The user-visible effect of using shlib-versions is that a macro appears in
> <gnu/lib-names.h>.  So it's not just a build-time question, it's an API
> issue as well.  Having a libgcc soname there seems entirely worthwhile to
> me--indicating which one libc uses, so an application can request the same
> one if it wants to get at the unwinder symbols or suchlike.  But it needs
> to be considered in that light, not merely as a question for the
> convenience of maintaining libc.
>
> As to the manual vs auto-detection, I think that is a more subtle question
> than you both are making it out to be.  We should be cautious, and I'm
> inclined to say that manual is better.
>
> This is not like other cases of detecting the features of the compiler
> being used to build libc.  This is about the runtime environment that the
> built libc will require of any system in which it is installed.  So you
> should think of auto-detecting it as more like auto-detecting a minimum
> kernel version for the --enable-kernel value, based on the kernel headers
> with which libc is built.  That would very obviously wrong to do.

You make a good point here.

Given that I'm inclined to say the way forward is probably:

* Stick with manual control.

* Move libgcc-so-name to shlib-versions.

* Add some configure sanity checks to ensure runtime matches expectations?

Cheers,
Carlos.