support for multiarch systems

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

Il 11/05/2012 07:13, Matthias Klose ha scritto:
> 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?

Thanks!  I don't think the search order should be mentioned specially,
since anyway *_INCLUDE_PATH and LIBRARY_PATH are mentioned.  However
under MULTILIB_DIRNAMES I would add something like this:

@code{MULTILIB_DIRNAMES} describes the multilib directories using GCC
conventions and is applied to directories that are part of the GCC
installation.  When multilib-enabled, the compiler will add a
subdirectory of the form @var{prefix}/@var{multilib} before each
directory in the search path for libraries and crt files.

> +@findex MULTILIB_OSDIRNAMES
> +@item MULTILIB_OSDIRNAMES
> +If @code{MULTILIB_OPTIONS} is used, this variable specifies

... a list of subdirectory names, that are used to modify the search
path depending on the chosen multilib.  Unlike @code{MULTILIB_DIRNAMES},
@code{MULTILIB_OSDIRNAMES} describes the multilib directories using
operating systems conventions, and is applied to the directories such as
@code{lib} or those in the @env{LIBRARY_PATH} environment variable.

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

s/OS/operating system/

> 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{!},

... GCC will not search in the non-multilib directory and use
exclusively the multilib directory.  Otherwise, the compiler will
examine the search path for libraries and crt files twice; the first
time it will add @var{multilib} to each directory in the search path,
the second it will not.

> Use the mapping when there is
> +no one-to-one equivalence between GCC levels and the OS.

I'm not sure what you mean here?


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

For configurations that support both multilib and multiarch,
@code{MULTILIB_OSDIRNAMES} also encodes the multiarch name, thus
subsuming @code{MULTIARCH_DIRNAME}.  The multiarch name is appended to
each directory name, separated by a colon (e.g.
@samp{../lib32:i386-linux-gnu}).

Each multiarch subdirectory will be searched before the corresponding OS
multilib directory, for example @samp{/lib/i386-linux-gnu} before
@samp{/lib/..lib32}.  The multiarch name will also be used to modify the
system header search path, as explained for @code{MULTIARCH_DIRNAME}.


> +@findex MULTIARCH_DIRNAME
> +@item MULTIARCH_DIRNAME
> +If @code{MULTIARCH_DIRNAME} is used, this variable specifies the
> +multiarch name for this configuration.
>
> +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}.
>
> +@code{MULTIARCH_DIRNAME} is not used for multilib enabled
> +configurations, but encoded in @code{MULTILIB_OSDIRNAMES} instead.

This sounds simpler, and doesn't refer to GCC implementation details
such add_prefix/add_sysrooted_prefix:

This variable specifies the multiarch name for configurations that are
multiarch-enabled but not multilibbed configurations.

The multiarch name is used to augment the search path for libraries, crt
files and system header files with additional locations.  The compiler
will add a multiarch subdirectory of the form
@var{prefix}/@var{multiarch} before each directory in the library and
crt search path.  It will also add two directories
@code{LOCAL_INCLUDE_DIR}/@var{multiarch} and
@code{NATIVE_SYSTEM_HEADER_DIR}/@var{multiarch}) to the system header
search path, respectively before @code{LOCAL_INCLUDE_DIR} and
@code{NATIVE_SYSTEM_HEADER_DIR}.

@code{MULTIARCH_DIRNAME} is not used for configurations that support
both multilib and multiarch.  In that case, multiarch names are encoded
in @code{MULTILIB_OSDIRNAMES} instead.

> +The multiarch tuples are defined
> +in @uref{http://wiki.debian.org/Multiarch/Tuples}.

Is this needed?  Aren't they defined simply by the GCC source code?
Surely if some other OS implements multiarch with different tuples (no
matter how undesirable that would be) Debian would not be an
authoritative source.

Paolo

Paolo Bonzini wrote:
> Il 11/05/2012 07:13, Matthias Klose ha scritto:

>> +The multiarch tuples are defined
>> +in @uref{http://wiki.debian.org/Multiarch/Tuples}.
>
> Is this needed?  Aren't they defined simply by the GCC source code?
> Surely if some other OS implements multiarch with different tuples (no
> matter how undesirable that would be) Debian would not be an
> authoritative source.

Is there some vendor-neutral wiki or other place that would be easy
to update that could be used to define tuples?  I think the table is
currently in that wiki page since that was just the easiest place to
put it.  As soon as there is some place more authoritative the table
could be replaced with a link.

If some other OS implements multiarch with different tuples, that's
no big deal.  An OS implementing multiarch using the same tuples with
incompatible meaning would be more unpleasant.

Jonathan