This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH 2/3] Define libgcc soname in make scripts and not in a header
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.