ld build configured with additional targets is broken

Matthias Klose doko@ubuntu.com
Fri Oct 28 12:38:00 GMT 2016


On 28.10.2016 09:04, Maciej W. Rozycki wrote:
> 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.

fyi, at least on mips-linux-gnu the native build is broken too (mipsel and
mips64el are not yet built):
https://buildd.debian.org/status/package.php?p=binutils&suite=experimental

Matthias



More information about the Binutils mailing list