31.3.2016, 14:43, onkel.jack@xxxxxxxxxxx kirjoitti:
--with-newlib= I took from a older recipie I had used for build gcc4.7, but youre right, doc does not say it has a arg
don't know where i originally got that from.
newlib-cygwin is not for Cygwin extensions, its just the repository name if you do a git clone from sourceware.org, the original newlib source. Had to use it since newlib-2.3.0 is broken for arm. (2.4.0 just got released, I use it now)
--enable-threads I would like to have to have thread safe stuff later on, my operating system provide them (to be integrated )
for now --enable-threads w/o an arg means single, this is no threads
--enable-interwork I may omit at all, I don't believe I really want to use mixed mode
but --enable-multilib is essentiell.
As told, I tried with multilib and interwork and it worked. First with
symlinked newlib-2.4.0 sources ('newlib'
and 'libgloss' subdirs in the main gcc-5.3.0 sources) so that newlib
would be built during the GCC build. This
wasn't installed. Then with a preinstalled old newlib-1.20 for
'arm-eabi', probably this was built with gcc-4.8.1.
Not yet sure about replacing the C library used with gcc-4.8, gcc-4.7,
gcc-4.6 etc which were installed earlier.
But the new gcc-5.3 parts were installed. Both cases succeeded nicely.
In the latter build I removed the
'--disable-threads' and '--disable-shared', thinking them being vain,
these being the defaults for 'arm-eabi' :
[root@localhost ~]# arm-eabi-gcc-5.3 -v
Using built-in specs.
COLLECT_GCC=arm-eabi-gcc-5.3
COLLECT_LTO_WRAPPER=/opt/cross/lib/gcc/arm-eabi/5.3.0/lto-wrapper
Target: arm-eabi
Configured with: ../configure --build=i686-linux-gnu
--host=i686-linux-gnu --target=arm-eabi --prefix=/opt/cross
--libdir=/opt/cross/lib --libexecdir=/opt/cross/lib --disable-nls
--enable-multilib --enable-interwork --disable-libffi
--enable-languages=c,c++ --with-newlib
--with-gxx-include-dir=/opt/cross/include/c++/5.3.0
--enable-version-specific-runtime-libs --program-prefix=arm-eabi-
--program-suffix=-5.3
Thread model: single
gcc version 5.3.0 (GCC)
So my thought is that the '--enable-threads' will cause problems if the
libstdc++-v3 configure doesn't know what
on earth threads the 'arm-eabi' would use. The GCC docs however tell
that this shouldn't make any difference
if the threads library is not defined :
--enable-threads
Specify that the target supports threads. This affects the Objective-C
compiler and runtime library, and exception handling for other languages
like C++ and Java. On some systems, this is the default.
In general, the best (and, in many cases, the only known) threading
model available will be configured for use. Beware that on some systems,
GCC has not been taught what threading models are generally available
for the system. In this case, --enable-threads is an alias for
--enable-threads=single.
--disable-threads
Specify that threading support should be disabled for the system. This
is an alias for --enable-threads=single.
--enable-threads=lib
Specify that lib is the thread support library. This affects the
Objective-C compiler and runtime library, and exception handling for
other languages like C++ and Java. The possibilities for lib are:
aix
AIX thread support.
dce
DCE thread support.
lynx
LynxOS thread support.
mipssde
MIPS SDE thread support.
no
This is an alias for ‘single’.
posix
Generic POSIX/Unix98 thread support.
rtems
RTEMS thread support.
single
Disable thread support, should work for all platforms.
tpf
TPF thread support.
vxworks
VxWorks thread support.
win32
Microsoft Win32 API thread support.
