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 Mon, Apr 9, 2012 at 1:21 PM, Siddhesh Poyarekar <siddhesh@redhat.com> wrote:
> On Fri, 6 Apr 2012 15:52:05 +0000 (UTC)
> "Joseph S. Myers" <joseph@codesourcery.com> wrote:
>> As I recall, when libgcc_s.h was added there was a discussion of
>> another possible approach, putting this soname in shlib-versions
>> files. ?Perhaps you could find that discussion and post references
>> with an analysis of the arguments made at the time and how the
>> approaches compare? ?Because that approach does seem quite a natural
>> one for providing this structured information.
>
> The main concern of this discussion:
>
> http://cygwin.com/ml/libc-alpha/2009-09/msg00041.html
>
> was whether we ought to *find* the libgcc_s version and use that or
> whether we maintain that by hand and the decision was to prefer to
> maintain it by hand since any move to a different libgcc version ought
> to be a conscious decision and not something that happens
> automatically.
>
> shlib-versions is to record information of binaries that we're
> building, so including libgcc information there does not seem like the
> right thing to do even if it may actually *work* functionally.

No need to be so rigid.

The shilb-versions file could include "shared library version numbers
we will install" *and* "shared library version numbers we depend upon
for correct operation."

As the developers of the project we can extend these frameworks to
meet our needs.

> I would actually like to revisit the idea of *finding* the soname from
> the built system since I can't see how it will really break anything.

I'm not against automatic detection of libgcc-so-name, but we need to
do so in a way that supports the ports, is properly isolated from the
native system (you may not be building against it), supports
overriding with config.cache, is cross-compile friendly, and works for
glibc-ports.

>> In any case, it would seem desirable to test for a port that uses a
>> nondefault soname here, making sure that a sysdeps definition of this
>> value using the new mechanism does work properly. ?There are two such
>> ports in the ports repository, hppa and m68k.
>
> This will break the ports; I hadn't thought of them when I wrote this. I
> think it'll be a better idea to somehow extract the value from
> libgcc_s.h. If we still want to stick to maintaining the soname by hand
> then I will rework this and resubmit.

Cheers,
Carlos.


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