From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3048 invoked by alias); 26 May 2012 17:51:26 -0000 Received: (qmail 3026 invoked by uid 22791); 26 May 2012 17:51:24 -0000 X-SWARE-Spam-Status: No, hits=-5.0 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,KHOP_RCVD_TRUST,KHOP_THREADED,RCVD_IN_DNSWL_LOW,RCVD_IN_HOSTKARMA_YE X-Spam-Check-By: sourceware.org Received: from mail-qa0-f41.google.com (HELO mail-qa0-f41.google.com) (209.85.216.41) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sat, 26 May 2012 17:51:11 +0000 Received: by qabg27 with SMTP id g27so253853qab.0 for ; Sat, 26 May 2012 10:51:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.182.194 with SMTP id cd2mr3072445qab.83.1338054670558; Sat, 26 May 2012 10:51:10 -0700 (PDT) Received: by 10.229.169.130 with HTTP; Sat, 26 May 2012 10:51:10 -0700 (PDT) In-Reply-To: References: <20120526133641.GA9655@intel.com> Date: Sat, 26 May 2012 17:51:00 -0000 Message-ID: Subject: Re: RFA: Port maintainers: Convert WORDSIZE[32|64]/ld to abi-variants From: "H.J. Lu" To: "Joseph S. Myers" Cc: GNU C Library , libc-ports@sourceware.org, Thomas Schwinge , Kaz Kojima , Andreas Krebbel Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Mailing-List: contact libc-ports-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: libc-ports-owner@sourceware.org X-SW-Source: 2012-05/txt/msg00167.txt.bz2 On Sat, May 26, 2012 at 10:02 AM, Joseph S. Myers wrote: > 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=3Dld-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 http://sourceware.org/git/?p=3Dglibc.git;a=3Dpatch;h=3D0d1f492b3cf83a200601= c1f49734b048c5547e57 >> 2. For biarch/triarch architectures where there are no soname difference= s, >> 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? Yes. >> 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 :=3D 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? =A0For 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). =A0I don't see an obvious new > location where that information is going, with the entries removed from > shlib-versions. 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. =A0(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. =A0SH 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? =A0And if they do need changes, please make them. =A0Verifyin= g 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.) > Thanks. --=20 H.J.