ld build configured with additional targets is broken

Maciej W. Rozycki macro@imgtec.com
Fri Oct 28 07:04:00 GMT 2016


On Thu, 27 Oct 2016, Matthias Klose wrote:

> gcc -DHAVE_CONFIG_H -I. -I../../ld  -I. -I../../ld -I../bfd -I../../ld/../bfd
> -I../../ld/../
> include  -g -O2 -DENABLE_PLUGINS -DLOCALEDIR="\"/usr/share/locale\""  -W -Wall
> -Wstrict-prot
> otypes -Wmissing-prototypes -Wshadow -Wstack-usage=262144
> -DELF_LIST_OPTIONS=TRUE -DELF_SHLI
> B_LIST_OPTIONS=TRUE -DELF_PLT_UNWIND_LIST_OPTIONS=TRUE -g -O2 -MT eelf32btsmip.o
> -MD -MP -MF
>  .deps/eelf32btsmip.Tpo -c -o eelf32btsmip.o eelf32btsmip.c
> In file included from /usr/include/x86_64-linux-gnu/sys/auxv.h:22:0,
>                  from eelf32btsmip.c:684:
> /usr/include/elf.h:1582:3: error: conflicting types for 'Elf32_gptab'
>  } Elf32_gptab;
>    ^~~~~~~~~~~
> In file included from eelf32btsmip.c:108:0:
> ../../ld/../include/elf/mips.h:534:3: note: previous declaration of
> 'Elf32_gptab' was here
>  } Elf32_gptab;
>    ^~~~~~~~~~~
> In file included from /usr/include/x86_64-linux-gnu/sys/auxv.h:22:0,
>                  from eelf32btsmip.c:684:
> [...]
> 
> The include is conditional for native builds, but apparently it doesn't take the
> configuration with additional targets into account.

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

 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 rename the types anyway, of course.

  Maciej



More information about the Binutils mailing list