public inbox for libc-ports@sourceware.org
 help / color / mirror / Atom feed
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

  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).