This is the mail archive of the
mailing list for the binutils project.
Re: ld build configured with additional targets is broken
> > 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.