From patchwork Fri May 11 05:13:44 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Matthias Klose X-Patchwork-Id: 158428 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) by ozlabs.org (Postfix) with SMTP id 4B794B6FA5 for ; Fri, 11 May 2012 15:14:16 +1000 (EST) Comment: DKIM? See http://www.dkim.org DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=gcc.gnu.org; s=default; x=1337318057; h=Comment: DomainKey-Signature:Received:Received:Received:Received: Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject: References:In-Reply-To:Content-Type:Mailing-List:Precedence: List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help:Sender: Delivered-To; bh=ZZZAy2y6GucJrJTKpAScnBk3Pkk=; b=AUYqUkfRvbP66RM Fo+NT4xnW8UnrUvMNkRWUoKUbMUfa7LcH0c5fK6MGBZ9JT6uO+kEXKlZbf2JsLZM O/T9Py2Ri2tzn8Qh0mC4hGJ/St+aqmQe+tOrKsR0aN8XrPjOl1TG1wbVV00VWD8y OQaLJULRZwB7SPfUHhWRyzeSDu4Q= Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gcc.gnu.org; h=Received:Received:X-SWARE-Spam-Status:X-Spam-Check-By:Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Mailing-List:Precedence:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help:Sender:Delivered-To; b=RJ9lmKePhTRwwN1NVL/g4LM8L+jBU8z1fIKVRf1p2OX5bxfSSx8AIxhRM0YRzL ulhHCdSJBCOGJB21sg4FcjVEekXwGUSwpnbOZ4CzBY14zEhkQOBO0pNJHQe6tUyt jcuppWggsLRnmSzuh5N0aOkDaBoqjw8sqysmJWXG6Qn9Q=; Received: (qmail 10331 invoked by alias); 11 May 2012 05:14:07 -0000 Received: (qmail 10323 invoked by uid 22791); 11 May 2012 05:14:04 -0000 X-SWARE-Spam-Status: No, hits=-2.2 required=5.0 tests=AWL, BAYES_00, KHOP_RCVD_UNTRUST, KHOP_THREADED, RCVD_IN_DNSWL_LOW X-Spam-Check-By: sourceware.org Received: from youngberry.canonical.com (HELO youngberry.canonical.com) (91.189.89.112) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 11 May 2012 05:13:51 +0000 Received: from [216.64.156.98] (helo=[10.155.43.193]) by youngberry.canonical.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1SSiAl-0000Z5-4G; Fri, 11 May 2012 05:13:47 +0000 Message-ID: <4FACA008.8040902@ubuntu.com> Date: Fri, 11 May 2012 07:13:44 +0200 From: Matthias Klose User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: Paolo Bonzini CC: "Joseph S. Myers" , GCC Patches Subject: Re: [patch] support for multiarch systems References: <4E501045.40102@ubuntu.com> <4FA8711D.3030507@ubuntu.com> <4FA9BC73.3080009@ubuntu.com> <4FAA730E.9020608@gnu.org> <4FAA8E89.3040800@ubuntu.com> <4FAA9B65.3040600@gnu.org> <4FAAA712.8010403@ubuntu.com> <4FAB6340.7030101@gnu.org> In-Reply-To: <4FAB6340.7030101@gnu.org> Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org On 10.05.2012 08:42, Paolo Bonzini wrote: > Il 09/05/2012 19:19, Matthias Klose ha scritto: >> these are referenced from the http://wiki.debian.org/Multiarch/Tuples >> https://wiki.ubuntu.com/MultiarchSpec#Filesystem_layout >> http://err.no/debian/amd64-multiarch-3 >> >> http://wiki.debian.org/Multiarch/TheCaseForMultiarch describes use cases for >> multiarch, and why Debian thinks that the existing approaches are not sufficient >> (having name collisions for different architectures or ad hoc names for new >> architectures like libx32). That may be contentious within the Linux community, >> but I would like to avoid this kind of discussion here. > > I don't care about contentiousness, I just would like this to be > documented somewhere (for example in the internals manual where > MULTILIB_* is documented too). ok, I did clarify it in the existing documentation of MULTIARCH_DIRNAME in fragments.texi, detailing the search order for the files. Should the search order be mentioned in some user documentation as well? if yes, where? Matthias Index: doc/fragments.texi =================================================================== --- doc/fragments.texi (revision 187337) +++ doc/fragments.texi (working copy) @@ -152,6 +152,52 @@ of options to be used for all builds. If you set this, you should probably set @code{CRTSTUFF_T_CFLAGS} to a dash followed by it. +@findex MULTILIB_OSDIRNAMES +@item MULTILIB_OSDIRNAMES +If @code{MULTILIB_OPTIONS} is used, this variable specifies the list +of OS subdirectory names. The format is either the same as of +@code{MULTILIB_DIRNAMES}, or a set of mappings. When it is the same +as @code{MULTILIB_DIRNAMES}, it describes the multilib directories +using OS conventions, rather than GCC conventions. When it is a set +of mappings of the form @var{gccdir}=@var{osdir}, the left side gives +the GCC convention and the right gives the equivalent OS defined +location. If the @var{osdir} part begins with a @samp{!}, the os +directory names are used exclusively. Use the mapping when there is +no one-to-one equivalence between GCC levels and the OS. + +For multilib enabled configurations (see @code{MULTIARCH_DIRNAME}) +below), the multilib name is appended to each directory name, separated +by a colon (e.g. @samp{../lib:x86_64-linux-gnu}). + +@findex MULTIARCH_DIRNAME +@item MULTIARCH_DIRNAME +If @code{MULTIARCH_DIRNAME} is used, this variable specifies the +multiarch name for this configuration. For multiarch enabled +configurations it is used to search libraries, crt files and system +header files in additional locations. + +Libraries and crt files are searched first in +@var{prefix}/@var{multiarch} before @var{prefix} for each @var{prefix} +added by @code{add_prefix} or @code{add_sysrooted_prefix}. +System header files are searched first in +@code{LOCAL_INCLUDE_DIR}/@var{multiarch} before +@code{LOCAL_INCLUDE_DIR}, and in +@code{NATIVE_SYSTEM_HEADER_DIR}/@var{multiarch} before +@code{NATIVE_SYSTEM_HEADER_DIR}. + +E.g. for a multiarch enabled system compiler +@file{/lib/@var{multiarch}} is searched before @file{/lib} and +@file{/usr/lib/@var{multiarch}} before @file{/usr/lib}, and system +header files are searched in @file{/usr/local/include/@var{multiarch}} +before @file{/usr/local/include} and in +@file{/usr/include/@var{multiarch}} before @file{/usr/include}. + +@code{MULTIARCH_DIRNAME} is not used for multilib enabled +configurations, but encoded in @code{MULTILIB_OSDIRNAMES} instead. + +The multiarch tuples are defined +in @uref{http://wiki.debian.org/Multiarch/Tuples}. + @findex SPECS @item SPECS Unfortunately, setting @code{MULTILIB_EXTRA_OPTS} is not enough, since