Re: ld build configured with additional targets is broken

[Nick Clifton <nickc at redhat dot com>]

Hi Maciej, Hi Matthias,

  Sorry about this.  I did wonder if including the <sys/auxv.h> header file would
cause problems, but I hoped that restricting it to native-only targets would be
sufficient.

>  This comes from the MIPS backend -- prompting me to speak out -- whose 
> target ELF header is among the few ones which have `ElfXX_*' type 
> definitions lacking an `External' or `Internal' marking in their name.

>  I suppose we could rename this type to `Elf32_Internal_gptab' and audit 
> the remaining cases,

I think that this is probably something that we ought to do in the long
term, regardless of how we solve this particular problem.  We definitely
should be avoiding name conflicts with system header files.  (Or else using
the definitions in the system header files, instead of our own local 
definitions ?  Would this work ?  Do we need the fields of the Elf32_gptab
structure to be 'unsigned long's ?)

> however this situation raises my concern about 
> including the system <elf.h> header in the first place, which may cause 
> conflicts and consequently compilation warnings (then promoted to hard 
> errors with `-Werror') with functionally equivalent although possibly 
> incompatible from the C preprocessor's point of view macro redefinitions, 
> which we have plenty, even if we rename all the types used.

I found that suppressing the inclusion of elf.h was an effective workaround
for the problem.  Ie:

 #ifdef HAVE_GETAUXVAL
+
+/* Prevent the inclusion of /usr/include/elf.h which contains
+   definitions that conflict with include/elf/mips.h.  */
+#define _ELF_H 1
+
 #include <sys/auxv.h>
 

>  So perhaps any call to `getauxval' would best be made from a wrapper 
> placed in a separate file by itself, where it'll be safe to include 
> <elf.h>, and consequently also <sys/auxv.h> which pulls it implicitly?

We could do this if you prefer, although it seems a little bit heavy handed,
especially since I am not even sure if supporting $PLATFORM is a good thing.

I prefer the workaround suggested above, myself, but what do you think ?

Cheers
  Nick