From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4428 invoked by alias); 10 Apr 2012 20:31:08 -0000 Received: (qmail 4402 invoked by uid 22791); 10 Apr 2012 20:31:05 -0000 X-SWARE-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,FREEMAIL_FROM,KHOP_RCVD_TRUST,KHOP_THREADED,RCVD_IN_DNSWL_LOW,RCVD_IN_HOSTKARMA_YE,TW_BH,TW_IB X-Spam-Check-By: sourceware.org Received: from mail-pb0-f41.google.com (HELO mail-pb0-f41.google.com) (209.85.160.41) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 10 Apr 2012 20:30:51 +0000 Received: by pbcup15 with SMTP id up15so415606pbc.0 for ; Tue, 10 Apr 2012 13:30:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.225.169 with SMTP id rl9mr15750757pbc.122.1334089851122; Tue, 10 Apr 2012 13:30:51 -0700 (PDT) Received: by 10.68.50.100 with HTTP; Tue, 10 Apr 2012 13:30:51 -0700 (PDT) In-Reply-To: References: <20120329193401.GA14860@dannf.org> <4F75F2E2.3030909@arm.com> <20120402210653.GC28152@dannf.org> Date: Tue, 10 Apr 2012 20:31:00 -0000 Message-ID: Subject: Re: [PATCH] ARM: Use different linker path for hardfloat ABI From: "Carlos O'Donell" To: Michael Hope Cc: "Joseph S. Myers" , dann frazier , Richard Earnshaw , "cross-distro@lists.linaro.org" , "gcc-patches@gcc.gnu.org" , libc-ports@sourceware.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes 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-04/txt/msg00021.txt.bz2 On Tue, Apr 3, 2012 at 6:56 PM, Joseph S. Myers w= rote: > (e) Existing practice for cases that do use different dynamic linkers is > to use a separate library directory, not just dynamic linker name, as in > lib32 and lib64 for MIPS or libx32 for x32; it's certainly a lot easier to > make two sets of libraries work in parallel if you have separate library > directories like that. =A0So it would seem more appropriate to define a > directory libhf for ARM (meaning you need a binutils patch as well to > handle that directory, I think), and these different Debian-style names > could be implemented separately in a multiarch patch if someone submits > one that properly accounts for my review comments on previous patch > versions (failure to produce such a fixed patch being why Debian multiarch > directory support has not got into GCC so far). The thread doesn't seem to be wrapping up, instead it appears to go in circles :-) As a glibc maintainer, when it comes to this issue, I am guided by: (1) This is a distribution problem and the solution needs to come from a consensus among the distributions. (2) The gcc/glibc community should listen to the distributions. The distributions have the most experience when it comes to whole-system issues. I certainly don't have that experience. Unfortunately *I* give the distributions a B- or C+ for communication. Please make it easy for me to give you an A. It is exceedingly difficult for me to review solutions that span multiple patches, emails, mailing lists, and communities. The best way to avoid rehashing old problems is to document the design and get sign off from the interested parties. If I see uncoordinated and conflicting responses from the distributions... I get worried. Is there a proposal on a wiki that begins to summarize the suggestions and solution? Cheers, Carlos.