Re: Building GDB with GCC 10 (-fno-common by default)

On 2020-07-01 5:29 a.m., Sebastian Huber wrote:
> Hello,
> 
> could this build error of the powerpc-rtems target be an issue with the 
> new -fno-common default of GCC 10?
> 
> make[3]: Entering directory 
> '/scratch/git-rtems-source-builder/rtems/build/powerpc-rtems6-gdb-4e394b2-x86_64-linux-gnu-1/build/sim/ppc'
> gcc -O2 -g -pipe 
> -I/scratch/git-rtems-source-builder/rtems/build/tmp/sb-10000/6/rtems-powerpc/build/rtems/6/include 
> -g -O2 -I. -I../../../sourceware-mirror-binutils-gdb-4e394b2/sim/ppc 
> -I../../../sourceware-mirror-binutils-gdb-4e394b2/sim/ppc/../../include 
> -I../../bfd 
> -I../../../sourceware-mirror-binutils-gdb-4e394b2/sim/ppc/../../bfd 
> -I../../gdb 
> -I../../../sourceware-mirror-binutils-gdb-4e394b2/sim/ppc/../../gdb 
> -I../../../sourceware-mirror-binutils-gdb-4e394b2/sim/ppc/../../gdb/config 
> -o igen igen.o table.o lf.o misc.o filter_host.o ld-decode.o ld-cache.o 
> filter.o ld-insn.o gen-model.o gen-itable.o gen-icache.o gen-semantics.o 
> gen-idecode.o gen-support.o
> /usr/lib64/gcc/x86_64-suse-linux/10/../../../../x86_64-suse-linux/bin/ld: 
> ld-insn.o:/scratch/git-rtems-source-builder/rtems/build/powerpc-rtems6-gdb-4e394b2-x86_64-linux-gnu-1/build/sim/ppc/../../../sourceware-mirror-binutils-gdb-4e394b2/sim/ppc/ld-insn.h:221: 
> multiple definition of `max_model_fields_len'; 
> igen.o:/scratch/git-rtems-source-builder/rtems/build/powerpc-rtems6-gdb-4e394b2-x86_64-linux-gnu-1/build/sim/ppc/../../../sourceware-mirror-binutils-gdb-4e394b2/sim/ppc/ld-insn.h:221: 
> first defined here
> 
> We have:
> 
> sim/ppc/ld-insn.h:int max_model_fields_len;
> sim/ppc/ld-insn.c:  if (max_model_fields_len < len)
> sim/ppc/ld-insn.c:    max_model_fields_len = len;
> sim/ppc/ld-insn.c:    if (max_model_fields_len < len)
> sim/ppc/ld-insn.c:      max_model_fields_len = len;
> sim/ppc/gen-model.c:            max_model_fields_len,
> sim/ppc/gen-model.c:        max_model_fields_len,
> 
> Missing extern in ld-insn.h and no definition in a source file?

Indeed, the .h should have an extern declaration, and there should be one definition to
allocate the storage, probably in ld-insn.c.  If that fixes the issue, would you mind
sending a patch?

Thanks,

Simon