Re: multilibs (Was: Re: -recursive)

[Ralf Corsepius]

On Thu, 2003-07-17 at 01:27, Alexandre Duret-Lutz wrote:
> >>> "Ralf" == Ralf Corsepius <address@hidden> writes:
> 
> [...]
> 
>  Ralf> Anyway, below is a test case triggering some of the nastinesses lurking
>  Ralf> in autoconf/automake and config-ml.in.
> 
> Thanks a lot!
> 
> [...]
> 
>  Ralf> Note: The tarball only works with VPATH builds (in-source-tree builds
>  Ralf> with multilibs also don't work.)
> 
>  >> (I'm not familiar with the multilib stuff though.)
>  Ralf> ... and I don't understand what you are doing with the recursive make
>  Ralf> targets in automake ... :(
> 
> Here is my attempt to turn your tarball into an Automake test
> case and to fix the issues that popped up.  The patch is against
> branch-1-7.
> 
> It tests VPATH and non-VPATH builds.  It also tests setups with
> and with SUBDIRS (the previous code in multilib.am was written
> conditionally wrt SUBDIRS but it's no longer the case).
> 
> I must insist that I'm completely ignorant of the multilib
> usage, so I'd really appreciate feedback on all this.
> Especially if you have improvements to suggest for the test case
> that would be welcome.  
I'll try your patch, but I probably won't be able to do so this week.

> For instance I can see that the multilib rules are triggered
> during the build, but I can't really ensure that they do work
> because `gcc -print-multi-lib' returns `.;' here.

This means that your gcc's target doesn't actually apply multilibs 
(".;" is the exceptional case of supporting only one multilib variant)

>   When does this print something different?
It returns something different for gcc-targets applying multilibs. 

These typically are compilers for embedded targets (In most cases
cross-compilers) but is not restricted to them.

For examples a sparc-rtems-gcc-3.2.3 cross-compiler returns this:
# sparc-rtems-gcc -print-multi-lib
.;
soft;@msoft-float
v8;@mcpu=v8
soft/v8;@address@hidden

In a nutshell, this means to compile a library 4 times (4 lines), using
the left side (left of the ';') of each line as directory suffix
(MULTISUBDIR) and the right side being appended to CFLAGS (config-ml.in
"seds" these flags into Makefiles).

[FWIW: RH-7.3 rpms of the toolchains I am using can be found on
ftp://ftp.rtems.com/pub/rtems/cd-working/tools]

A less exotic case, for example would be a sparc-sun-solaris2.7-gcc-3.3:
# sparc-sun-solaris2.7-gcc -print-multi-lib
.;
sparcv9;@m64

> Is that a situation we can
> easily trigger in a test case?
I could imagine several possibilities:

1. Skip such a test if a compiler doesn't support -print-multi-lib
and/or -print-multi-lib return ".;" only

2. Use a wrapper script to emulate -print-multi-lib.

In brief, some script similar to this could work:
#! /bin/sh 
case ${1+"$@"} in
 *-print-multi-lib*)
  echo ".;"
  echo "debug;@g"
  exit 0 ;;
esac
@REALCC@ ${1+"$@"}

And add something similar to this to configure.in
AC_SUBST(REALCC,$CC)
AC_CONFIG_FILES([mycc:mycc.in],[chmod +x mycc])

Then let the test apply CC=mycc.

This doesn't really emulate full multilib support (multilib support
internally of gcc affects library search paths and further settings)

> Also, is it normal that I have to use --with-target-subdir=.
> in non-VPATH builds?
Hmm, --with-target-subdir is meant to contain the root directory name of
a target subtree for mixed-target builds (building for several target"
in one single build run). 

It typically contains $target or $target_alias or is empty for native
building. It typically is added to the commandline of subdirectory
configure scripts by toplevel configure scripts, similar to this

mkdir -p $target/libfoo
cd $target/foo
$top_srcdir/libfoo/configure --with-target-subdir=$target \
--host=$target_alias

So, --with-target-subdir=. actually could be a work-around to get
non-VPATH builds "buildable" ;-)
[non-VPATH build with multilibs can create arbitrary directories inside
of the sourcedir and therefore can trash your sourcetree. AFAIK,
therefore non-VPATH builds with multilibs are not really supported.]

Ralf