From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ian Lance Taylor To: nickc@cygnus.com Cc: devans@cygnus.com, binutils@sourceware.cygnus.com Subject: Re: Should the linker tests notice multilib variations ? Date: Tue, 13 Jul 1999 10:34:00 -0000 Message-id: <19990713173308.4945.qmail@daffy.airs.com> References: <199907131720.SAA19780@pathia.cygnus.co.uk> X-SW-Source: 1999-q3/msg00181.html Date: Tue, 13 Jul 1999 18:20:21 +0100 From: Nick Clifton 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