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