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 [EMAIL PROTECTED] (916) 791-8304
