This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]