Re: --target=powerpc-eabi: error: static declaration of ‘strndup’ follows non-static declaration

Kai Ruottu
Thu Nov 9 11:46:00 GMT 2017

Kai Ruottu kirjoitti 9.11.2017 klo 13:17:

> My old slow 32-bit Linux PC is still producing libstdc++-v3... Forgot 
> to disable multilib which made it
> still slower :(  But producing newlib-2.5 with gcc-7.2.0 for ppc-eabi 
> succeeded without problems
> (it didn't stop anywhere).  Ok, now it did stop here :
> Checking multilib configuration for libbacktrace...
> Configuring in ppc-eabi/libbacktrace
> configure: loading cache ./config.cache
> checking build system type... i686-pc-linux-gnu
> checking host system type... powerpc-unknown-eabi
> checking target system type... powerpc-unknown-eabi
> checking for ppc-eabi-gcc... /home/src-old/gcc-7.2.0/build/./gcc/xgcc 
> -B/home/src-old/gcc-7.2.0/build/./gcc/ -nostdinc 
> -B/home/src-old/gcc-7.2.0/build/ppc-eabi/newlib/ -isystem 
> /home/src-old/gcc-7.2.0/build/ppc-eabi/newlib/targ-include -isystem 
> /home/src-old/gcc-7.2.0/newlib/libc/include 
> -B/home/src-old/gcc-7.2.0/build/ppc-eabi/libgloss/rs6000 
> -L/home/src-old/gcc-7.2.0/build/ppc-eabi/libgloss/libnosys 
> -L/home/src-old/gcc-7.2.0/libgloss/rs6000 -B/opt/cross/ppc-eabi/bin/ 
> -B/opt/cross/ppc-eabi/lib/ -isystem /opt/cross/ppc-eabi/include 
> -isystem /opt/cross/ppc-eabi/sys-include
> checking for C compiler default output file name...
> configure: error: in 
> `/home/src-old/gcc-7.2.0/build/ppc-eabi/libbacktrace':
> configure: error: C compiler cannot create executables
> Of course the "target system" for ppc-eabi is something unknown so no 
> default startups, libgloss, linker script
> etc... So no executables for it as default. Why the '--with-newlib' 
> didn't cause disabling all linking tests is weird.

Seemingly this wasn't the problem... What I didn't tell was that in the 
beginning I only had some old binutils-2.19
from 2010 for 'ppc-eabi' and in wrong $prefix, '/usr/local', instead the 
current, '/opt/cross', I had used. So the
target binutils weren't found and at least the generated 'gcc/as', 
'gcc/nm' and 'gcc/collect-ld' were faulty. Deleting
these, latest the latter, didn't help. So I started the build from the 
beginning after adding the '--disable-multilib'.
The up-to-date binutils were built and installed into the right $prefix 
when I got problems already in the 'libgcc'
build because of the faulty 'gcc/as' and 'gcc/nm'. Wasn't the first time 
during this '/usr/local' --> '/opt/cross'
switch so the problem was easy to grok...

More information about the Gcc-help mailing list