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
