gcc.dg/compat/struct-layout-1.exp does not supported installed-compilertesting

[Mark Mitchell <mark at codesourcery dot com>]

This test doesn't support testing an installed compiler.

The root of the problem is that the test generator is written as a C
program, which is expected to be run on the host system.  As a result,
we need to compile on the host system, which is why we need HOSTCC and
HOSTCFLAGS in struct-layout-1.exp.

That itself is not a fatal flaw, but the generator program also wants to 
use "config.h", "hashtab.h", "libiberty.h", and "getopt.h".

Now, config.h we can probably just do without; that's being used to 
define things like HAVE_LIMITS_H, and if the host system was capable of 
building GCC, it's got <limits.h>.  Technically, we're requiring a C89 
copmiler, but not a C89 library, but I'm not worried abouts <limits.h>, 
<string.h>, and <stdlib.h>, which are the headers for which we're 
testing.  (Furthermore, if the host system doesn't have <limits.h>, the 
program won't compile anyhow, so, empirically, all systems on which 
people are running the testsuite have that header file, and there's not 
much point in using HAVE_LIMITS_H if we don't make the code somehow work 
when <limits.h> isn't defined.)

However, since we don't actually install the libiberty headers (though, 
curiously, we do install lib/libiberty.a), we don't have a shot at the 
other headers.  Even that might be surivable, in that we could provide 
explicit prototypes, but we are using INSERT from hashtab.h, and 
copying that definition into the generator program seems too disgusting.

(Now, in retrospect, the most reliable way to do this would have been to 
write the generator program in Tcl, and, in fact, I think that should be 
our policy henceforth for any similar programs.  Despite all the bad 
things people say about Tcl, it's perfectly possible to right decent 
code using it, and -- like it or not -- it's the language in which our 
testsuite is written.  However, unless someone wants to rewrite this 
program in Tcl, we've got to figure out what to do about this situation.)

Anyhow, why do we install libiberty.a, but not the libiberty include 
files?  If we defaulted to --enable-install-libiberty, then most GCC 
installations would have the headers, and we'd be OK.  If that's the 
wrong thing to do, then my back-up plan is to:

1. Remove the use of config.h and HAVE_*_H.

2. Modify the generator not to depend on libiberty headers, including 
hashtab.h, by substituting a simple dictonary object.

3. Adjust struct-layout-1.exp accordingly.

Thoughts?

--
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com
(916) 791-8304