Re: Should the linker tests notice multilib variations ?

[Ian Lance Taylor <ian@zembu.com>]

   Date: Tue, 13 Jul 1999 18:20:21 +0100
   From: Nick Clifton <nickc@cygnus.com>

   The problem however is more general than that.  If my patch were to be
   applied then we would start running into all kinds of problems with
   failed links because the switches and library search directories
   passed to the linker would not match up with the binaries being
   produced by the compiler.

   The endian problem is one example of this.  The compiler is passed the
   -mbig-endian switch, produces a big-endian object file, and then the
   link fails because it uses a linker script which only uses the default
   output format which is (say) little endian.

   But the problem is not restricted to endianism.  Any multilib option
   which has an effect at link time is going to cause problems.  Suppose
   for example that a target has two different APIs and multilibs are
   provided for both versions.  When the linker tests are run only the
   default libraries will be found (because gcc is not being used to
   drive the link process), and so there will be link time fails when
   binaries for one API are linked with libraries for the other API.

Most of the linker tests are intentionally not linked against any
other libraries.

The exceptions are tests like bootstrap and cdtest, in which the
linker generates an executable which is then run.  Those tests
naturally only work on native systems.  Most native systems don't use
multilibs, so my offhand thinking is that we need not worry about them
too much.

   The only way to be sure that correct executables are produced is to
   allow gcc to do the linking as well as the compiling, rather than
   invoking the linker directly (since gcc may have to translate some
   command line in order for the linker to understand them, and it also
   has to sort out the paths to the multilib libraries), and to always
   use the built in linker script which will support multiple output
   formats.  

I wouldn't object to doing this for tests which must build an
executable which is to be run.  However, the tests need to work if gcc
is not present, so there needs to be a reasonable fallback.

   I am not sure if the first requirement will be a problem.  Currently
   the linker testsuite invokes the linker directly, and presumably there
   is a good reason for this.

It's desirable to be able to test the linker independently from gcc.
It's OK to assume that gas is present, since they are both in the
binutils.  It's not OK to assume that gcc, or indeed any compiler, is
present.  I'm sure you yourself have been in the position of testing
the binutils for a target for which you do not have any compiler.

   The second requirement is too restrictive however, as the linker 
   tests need to be able to use their own scripts.  This is where Ian's
   suggestion comes in.

As far as I know, the linker tests which use their own scripts do not
link against any other libraries.

Ian