This is the mail archive of the
mailing list for the glibc project.
Re: RFA: Port maintainers: Convert WORDSIZE[32|64]/ld to abi-variants
- From: "H.J. Lu" <hjl dot tools at gmail dot com>
- To: "Joseph S. Myers" <joseph at codesourcery dot com>
- Cc: GNU C Library <libc-alpha at sourceware dot org>, libc-ports at sourceware dot org, Thomas Schwinge <thomas at codesourcery dot com>, Kaz Kojima <kkojima at rr dot iij4u dot or dot jp>, Andreas Krebbel <Andreas dot Krebbel at de dot ibm dot com>
- Date: Sat, 26 May 2012 10:51:10 -0700
- Subject: Re: RFA: Port maintainers: Convert WORDSIZE[32|64]/ld to abi-variants
- References: <20120526133641.GA9655@intel.com><Pine.LNX.email@example.com>
On Sat, May 26, 2012 at 10:02 AM, Joseph S. Myers
> On Sat, 26 May 2012, H.J. Lu wrote:
>> 1. For non-biarch architectures, there is nothing to do.
> This patch is removing the ld=ld-linux.so.2 entry for sh.*-.*-linux.*,
> which looks like a mistake; I don't see it added anywhere else.
I restored sh and sparc entries in shlib-versions on hjl/abi branch.
The new patch is at
>> 2. For biarch/triarch architectures where there are no soname differences,
>> you need to rename syscall-list-* variables in CPU/Makefile to abi-*.
>> If the default ABI for the build isn't the first one on abi-variants, you
>> should also define default-abi:
> But leave the sonames in shlib-versions?
>> 3. For biarch/triarch architectures where there are soname differences,
>> in addition to renaming syscall-list-* variables in CPU/Makefile to
>> abi-* and defining default-abi, you also need to define
>> abi-XX-ld-soname := your ld.so soname.
>> where XX is the ABI variant, like
> And leave sonames in shlib-versions as well, or take them out?
> If taken out, where does the minimum symbol version information for ld.so
> go? ?For sparc64 it's currently given as GLIBC_2.2 - not globally, but for
> ld.so (sparc64 has GLIBC_2.0 symbols in some libraries such as libresolv,
> but for ld.so, libc, libm and libpthread the minimum is GLIBC_2.2; I don't
> know the story behind why this is the case). ?I don't see an obvious new
> location where that information is going, with the entries removed from
I restored sparc entries in shlib-versions to accommodate this.
> We could probably do with each libc architecture maintainer confirming
> that their ABI tests still pass after the changes. ?(Well, that may be
> hard for S390 and SH, whose ABI baselines haven't been updated by the
> architecture maintainers since they were moved to separate
> per-architecture files. ?SH and S390 maintainers, if your baselines are in
> fact accurate without changes - if the tests pass as-is (you can run make
> check-abi from cross as well as native builds) and comparison with other
> architectures and old binaries doesn't show any signs of mistakes having
> crept into past symbol versions - could you please confirm that
> explicitly? ?And if they do need changes, please make them. ?Verifying the
> check-abi tests pass is something to be done for all architectures between
> freeze and release - but the only problems it should be discovering at
> that point are *recent* ABI breakage; mistakes in the baseline, or
> unwanted changes relative to binaries of old releases, ought to be found
> in advance of the freeze.)