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: PowerPC LE configury


On Fri, 30 Aug 2013, Roland McGrath wrote:

> The strawman idea is that sysdeps makefiles or configure or something would
> just set some variable like 'abi-name'.  Then we'd look for
> $(libname)-$(abi-name).abilist instead of $(libname).abilist.  (The only
> reason then to look in sysdeps dirs instead of one common place is so that
> add-on ports can supply them.)
> 
> We'd also discussed using that same name instead of the actual config tuple
> as the lookup key for shlib-versions and perhaps some other such things.
> But those can be follow-on changes.
> 
> Joseph might remember more details of what we've discussed in this area
> before and/or have wiki or archive links handy.

<https://sourceware.org/ml/libc-alpha/2012-03/msg00589.html> discusses 
defining ABI names as the key used in shlib-versions instead of regular 
expressions.

We do still have the names defined by ABI entries in shlib-versions - but 
abi-name isn't actually used for anything any more, since we moved files 
to sysdeps on the general principle of putting system-specific files 
there.  I'm not sure the names currently defined by abi-name are actually 
particularly reliable at indicating ABI distinctions, either.  So we 
probably want to rethink from scratch what we want these ABI names to look 
like, given the existing systems supported by glibc.  (For example, if an 
architecture supports both big and little endian, do those always get 
separate ABI names, or only if they have different symbol versions?)

Separately, the variable abi-variants (and associated other makefile 
variables) is used in generating gnu/stubs.h, gnu/lib-names.h and (for 
Linux) bits/syscall.h.  lib-names.h generation currently needs SONAME 
information for ABI variants to be duplicated in makefile variables.  It 
also presents a problem for fully moving shlib-versions contents to 
sysdeps directories if that duplication is removed, as noted in 
<https://sourceware.org/ml/libc-alpha/2012-03/msg00606.html> (although 
certainly the architecture-specific contents should move to sysdeps 
directories as far as possible - but maybe that would be a single 
shlib-versions file in sysdeps/x86 for all x86 variants, rather than 
separate files for each variant).

-- 
Joseph S. Myers
joseph@codesourcery.com


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