This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: ld build configured with additional targets is broken


Nick,

> >  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 ?)

 I think we can't and don't want to rely on system headers for ELF 
definitions as there can be none when a cross-toolchain is being built.  
We still support non-ELF hosts and the MinGW remains one of particular 
importance I believe.

> > 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>

 I agree with Florian this is a hack we cannot use.

> >  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 have no opinion on $PLATFORM offhand.

  Maciej


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]