This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [patch] support for multiarch systems
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