From: "Joseph S. Myers" <joseph@codesourcery.com>
To: "H.J. Lu" <hjl.tools@gmail.com>
Cc: GNU C Library <libc-alpha@sourceware.org>,
libc-ports@sourceware.org,
Thomas Schwinge <thomas@codesourcery.com>,
Kaz Kojima <kkojima@rr.iij4u.or.jp>,
Andreas Krebbel <Andreas.Krebbel@de.ibm.com>
Subject: Re: RFA: Port maintainers: Convert WORDSIZE[32|64]/ld to abi-variants
Date: Sat, 26 May 2012 17:03:00 -0000 [thread overview]
Message-ID: <Pine.LNX.4.64.1205261648450.16948@digraph.polyomino.org.uk> (raw)
In-Reply-To: <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
shlib-versions.
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
joseph@codesourcery.com
next prev parent reply other threads:[~2012-05-26 17:03 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-05-26 13:37 H.J. Lu
2012-05-26 17:03 ` Joseph S. Myers [this message]
2012-05-26 17:51 ` H.J. Lu
2012-05-26 19:22 ` Joseph S. Myers
2012-05-26 20:42 ` H.J. Lu
2012-05-30 0:29 ` H.J. Lu
2012-05-30 0:39 ` David Miller
2012-05-30 3:15 ` David Miller
2012-05-30 3:27 ` H.J. Lu
2012-05-30 8:49 ` Andreas Krebbel
2012-05-30 13:00 ` H.J. Lu
2012-05-31 15:17 ` Joseph S. Myers
2012-05-31 15:32 ` H.J. Lu
2012-06-01 14:06 ` Joseph S. Myers
2012-06-01 14:21 ` H.J. Lu
2012-06-01 15:07 ` Joseph S. Myers
2012-06-01 15:27 ` H.J. Lu
2012-06-01 20:16 ` Joseph S. Myers
2012-06-01 20:32 ` Roland McGrath
2012-05-30 18:58 ` Thomas Schwinge
2012-05-30 19:00 ` H.J. Lu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Pine.LNX.4.64.1205261648450.16948@digraph.polyomino.org.uk \
--to=joseph@codesourcery.com \
--cc=Andreas.Krebbel@de.ibm.com \
--cc=hjl.tools@gmail.com \
--cc=kkojima@rr.iij4u.or.jp \
--cc=libc-alpha@sourceware.org \
--cc=libc-ports@sourceware.org \
--cc=thomas@codesourcery.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).