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: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: "H.J. Lu" <hjl dot tools at gmail 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 17:02:58 +0000 (UTC)
- Subject: Re: RFA: Port maintainers: Convert WORDSIZE[32|64]/ld to abi-variants
- References: <20120526133641.GA9655@intel.com>
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.
> 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
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.)
Joseph S. Myers