Yahoo Groups archive

Lpc2000

Index last updated: 2026-04-28 23:31 UTC

Thread

Newlib problem

Newlib problem

2005-04-04 by Leonardo Santos

Hello All:
	First, than you all for the answers on my previous question about a C union 
not working for IO access. I'm now compiling some programs with GCC 3.4.3 and 
newlib 1.12. I've download the source packages from http://rod.info/arm.html 
and used his build script to build the toolchain. All went very smooth.
	I've been able to compile FreeRTOS for LPC2106 and tried to blink some LEDs 
(hence the question about the C union), but when I try to use any code from 
the newlib, I get the following warning:

arm-elf-ld: Warning: /opt/arm/lib/gcc/arm-elf/3.4.3//libgcc.a(_udivsi3.o) does 
not support interworking, whereas test2.prg does

And a little but further:

arm-elf-ld:   first 
occurrence: /opt/arm/lib/gcc/arm-elf/3.4.3/../../../../arm-elf/lib//libc.a(mallocr.o): 
thumb call to arm

I checked the build script against the GNU ARM page and they both build newlib 
with the --enable-interwork --enable-multilib options. So I though I had 
interwork enabled. The only google reference I got 
( http://www.codesourcery.com/archives/arm-gnu/msg00030.html ) tells this:

"If you do require thumb interworking you will need to recompile both the C 
library (newlib) and compiler support library (libgcc) with interworking 
support."

The build scrip and GNU ARM both build GCC with the --enable-interwork 
--enable-multilib --with-newlib options. So I'm a bit confused: Is this 
anewlib problem, a GCC problem or a compilation problem of my app? Thanks a 
lot!

-- 
This is Linux country.
On a quiet night, you can hear Windows reboot.

Leonardo Pereira Santos
Engenheiro de Projetos
PD3 Tecnologia
av. Pará 330/202
(51) 3337 1237

Re: [lpc2000] Newlib problem

2005-04-04 by Robert Adsett

At 12:00 PM 4/4/05 -0300, Leonardo Santos wrote:
>         First, than you all for the answers on my previous question about 
> a C union
>not working for IO access. I'm now compiling some programs with GCC 3.4.3 and
>newlib 1.12. I've download the source packages from http://rod.info/arm.html
>and used his build script to build the toolchain. All went very smooth.
>         I've been able to compile FreeRTOS for LPC2106 and tried to blink 
> some LEDs
>(hence the question about the C union), but when I try to use any code from
>the newlib, I get the following warning:
>
>arm-elf-ld: Warning: /opt/arm/lib/gcc/arm-elf/3.4.3//libgcc.a(_udivsi3.o) 
>does
>not support interworking, whereas test2.prg does

It's complaining that the C compiler library is not compiled with 
internetworking.  In this case it's trying to link in a division 
routine.  Newlib does not provide these, they are built with gcc normally.

Robert

" 'Freedom' has no meaning of itself.  There are always restrictions,   be 
they legal, genetic, or physical.  If you don't believe me, try to chew a 
radio signal. "  -- Kelvin Throop, III
http://www.aeolusdevelopment.com/

Re: [lpc2000] Newlib problem

2005-04-04 by Leonardo Santos

Rebuilding my toolchain and searching where _udivsi3.o was compiled, I noticed 
that there are four versions of libgcc.a:

lib/gcc/arm-elf/3.4.3
lib/gcc/arm-elf/3.4.3/thumb
lib/gcc/arm-elf/3.4.3/interwork
lib/gcc/arm-elf/3.4.3/thumb/interwork

The first is compiled with no options. The second with -mthumb, the third with 
-mthumb-interwork and the last one with -mthumb -mthumb-interwork. By using 
-L to include the appropriate one (in my case, 
lib/gcc/arm-elf/3.4.3/interwork), all erros went away. So sorry for raising a 
flag for no reason.
Thanks a lot!

On Monday 04 April 2005 13:01, Robert Adsett wrote:
> At 12:00 PM 4/4/05 -0300, Leonardo Santos wrote:
> >         First, than you all for the answers on my previous question about
> > a C union
> >not working for IO access. I'm now compiling some programs with GCC 3.4.3
> > and newlib 1.12. I've download the source packages from
> > http://rod.info/arm.html and used his build script to build the
> > toolchain. All went very smooth. I've been able to compile FreeRTOS for
> > LPC2106 and tried to blink some LEDs
> >(hence the question about the C union), but when I try to use any code
> > from the newlib, I get the following warning:
> >
> >arm-elf-ld: Warning: /opt/arm/lib/gcc/arm-elf/3.4.3//libgcc.a(_udivsi3.o)
> >does
> >not support interworking, whereas test2.prg does
>
> It's complaining that the C compiler library is not compiled with
> internetworking.  In this case it's trying to link in a division
> routine.  Newlib does not provide these, they are built with gcc normally.
>
> Robert
>
> " 'Freedom' has no meaning of itself.  There are always restrictions,   be
> they legal, genetic, or physical.  If you don't believe me, try to chew a
> radio signal. "  -- Kelvin Throop, III
> http://www.aeolusdevelopment.com/
>
>
>
>
> Yahoo! Groups Links
>
>
>

-- 
This is Linux country.
On a quiet night, you can hear Windows reboot.

Leonardo Pereira Santos
Engenheiro de Projetos
PD3 Tecnologia
av. Pará 330/202
(51) 3337 1237

Today Fortune tells us:
Fortune Documents the Great Legal Decisions:

We can imagine no reason why, with ordinary care, human toes could not be
left out of chewing tobacco, and if toes are found in chewing tobacco, it
seems to us that someone has been very careless.
		-- 78 So. 365.

Re: Newlib problem

2005-04-05 by ntfreak2000

--- In lpc2000@yahoogroups.com, Leonardo Santos <lsantos@p...> wrote:
> Rebuilding my toolchain and searching where _udivsi3.o was 
compiled, I noticed 
> that there are four versions of libgcc.a:
> 
> lib/gcc/arm-elf/3.4.3
> lib/gcc/arm-elf/3.4.3/thumb
> lib/gcc/arm-elf/3.4.3/interwork
> lib/gcc/arm-elf/3.4.3/thumb/interwork
> 
> The first is compiled with no options. The second with -mthumb, the 
third with 
> -mthumb-interwork and the last one with -mthumb -mthumb-interwork. 
By using 
> -L to include the appropriate one (in my case, 
> lib/gcc/arm-elf/3.4.3/interwork), all erros went away. So sorry for 
raising a 
> flag for no reason.
> Thanks a lot!
> 
> On Monday 04 April 2005 13:01, Robert Adsett wrote:
> > At 12:00 PM 4/4/05 -0300, Leonardo Santos wrote:
> > >         First, than you all for the answers on my previous 
question about
> > > a C union
> > >not working for IO access. I'm now compiling some programs with 
GCC 3.4.3
> > > and newlib 1.12. I've download the source packages from
> > > http://rod.info/arm.html and used his build script to build the
> > > toolchain. All went very smooth. I've been able to compile 
FreeRTOS for
> > > LPC2106 and tried to blink some LEDs
> > >(hence the question about the C union), but when I try to use 
any code
> > > from the newlib, I get the following warning:
> > >
> > >arm-elf-ld: Warning: /opt/arm/lib/gcc/arm-elf/3.4.3//libgcc.a
(_udivsi3.o)
> > >does
> > >not support interworking, whereas test2.prg does
> >
> > It's complaining that the C compiler library is not compiled with
> > internetworking.  In this case it's trying to link in a division
> > routine.  Newlib does not provide these, they are built with gcc 
normally.
> >
> > Robert


It sounds like you are calling ld directly on the command line.
If you use gcc to perform the link then the correct libs will always 
be used.

Regards
Spen

Re: [lpc2000] Re: Newlib problem

2005-04-05 by Anton Erasmus

On 5 Apr 2005 at 9:02, ntfreak2000 wrote:

> 
> 
> --- In lpc2000@yahoogroups.com, Leonardo Santos <lsantos@p...> wrote:
> > Rebuilding my toolchain and searching where _udivsi3.o was compiled,
> I noticed > that there are four versions of libgcc.a: > >
> lib/gcc/arm-elf/3.4.3 > lib/gcc/arm-elf/3.4.3/thumb >
> lib/gcc/arm-elf/3.4.3/interwork >
> lib/gcc/arm-elf/3.4.3/thumb/interwork > > The first is compiled with
> no options. The second with -mthumb, the third with >
> -mthumb-interwork and the last one with -mthumb -mthumb-interwork. By
> using > -L to include the appropriate one (in my case, >
> lib/gcc/arm-elf/3.4.3/interwork), all erros went away. So sorry for
> raising a > flag for no reason. > Thanks a lot! > > On Monday 04 April
> 2005 13:01, Robert Adsett wrote: > > At 12:00 PM 4/4/05 -0300,
> Leonardo Santos wrote: > > >         First, than you all for the
> answers on my previous question about > > > a C union > > >not working
> for IO access. I'm now compiling some programs with GCC 3.4.3 > > >
> and newlib 1.12. I've download the source packages from > > >
> http://rod.info/arm.html and used his build script to build the > > >
> toolchain. All went very smooth. I've been able to compile FreeRTOS
> for > > > LPC2106 and tried to blink some LEDs > > >(hence the
> question about the C union), but when I try to use any code > > > from
> the newlib, I get the following warning: > > > > > >arm-elf-ld:
> Warning: /opt/arm/lib/gcc/arm-elf/3.4.3//libgcc.a (_udivsi3.o) > >
> >does > > >not support interworking, whereas test2.prg does > > > >
> It's complaining that the C compiler library is not compiled with > >
> internetworking.  In this case it's trying to link in a division > >
> routine.  Newlib does not provide these, they are built with gcc
> normally. > > > > Robert
> 
> 
> It sounds like you are calling ld directly on the command line.
> If you use gcc to perform the link then the correct libs will always
> be used.
> 

Unfortunately that does not appear to be the case. I have a similar problem in that
the correct libraries are not automatically being used. I am definitely linking using gcc
and not ld. When using the arm-elf binary toolset from http://www.gnuarm.com under
cygwin, my code links with the correct libraries. If I use the linux binaries from the same
site under RH9, I get similar errors. When using tools built from source using Rod 
Moffit's excellent buildscript, I also get the errors. I can also manually force the link with
the correct libraries, but this is a pain. Where / How does gcc decide which libraries
to use when linking ? Also if one wants to use some of the less common compile 
options, that result in binary incompatibilities, how can one build a libgcc with the same 
options ? e.g. if one wants to use the option -fpack-struct.

Regards
   Anton Erasmus
-- 
A J Erasmus

Re: Newlib problem

2005-04-05 by ntfreak2000

--- In lpc2000@yahoogroups.com, "Anton Erasmus" <antone@s...> wrote:
> On 5 Apr 2005 at 9:02, ntfreak2000 wrote:
> 
> > 
> > 
> > --- In lpc2000@yahoogroups.com, Leonardo Santos <lsantos@p...> 
wrote:
> > > Rebuilding my toolchain and searching where _udivsi3.o was 
compiled,
> > I noticed > that there are four versions of libgcc.a: > >
> > lib/gcc/arm-elf/3.4.3 > lib/gcc/arm-elf/3.4.3/thumb >
> > lib/gcc/arm-elf/3.4.3/interwork >
> > lib/gcc/arm-elf/3.4.3/thumb/interwork > > The first is compiled 
with
> > no options. The second with -mthumb, the third with >
> > -mthumb-interwork and the last one with -mthumb -mthumb-
interwork. By
> > using > -L to include the appropriate one (in my case, >
> > lib/gcc/arm-elf/3.4.3/interwork), all erros went away. So sorry 
for
> > raising a > flag for no reason. > Thanks a lot! > > On Monday 04 
April
> > 2005 13:01, Robert Adsett wrote: > > At 12:00 PM 4/4/05 -0300,
> > Leonardo Santos wrote: > > >         First, than you all for the
> > answers on my previous question about > > > a C union > > >not 
working
> > for IO access. I'm now compiling some programs with GCC 3.4.3 > > 
>
> > and newlib 1.12. I've download the source packages from > > >
> > http://rod.info/arm.html and used his build script to build the > 
> >
> > toolchain. All went very smooth. I've been able to compile 
FreeRTOS
> > for > > > LPC2106 and tried to blink some LEDs > > >(hence the
> > question about the C union), but when I try to use any code > > > 
from
> > the newlib, I get the following warning: > > > > > >arm-elf-ld:
> > Warning: /opt/arm/lib/gcc/arm-elf/3.4.3//libgcc.a (_udivsi3.o) > >
> > >does > > >not support interworking, whereas test2.prg does > > > 
>
> > It's complaining that the C compiler library is not compiled with 
> >
> > internetworking.  In this case it's trying to link in a division 
> >
> > routine.  Newlib does not provide these, they are built with gcc
> > normally. > > > > Robert
> > 
> > 
> > It sounds like you are calling ld directly on the command line.
> > If you use gcc to perform the link then the correct libs will 
always
> > be used.
> > 
> 
> Unfortunately that does not appear to be the case. I have a similar 
problem in that
> the correct libraries are not automatically being used. I am 
definitely linking using gcc
> and not ld. When using the arm-elf binary toolset from 
http://www.gnuarm.com under
> cygwin, my code links with the correct libraries. If I use the 
linux binaries from the same
> site under RH9, I get similar errors. When using tools built from 
source using Rod 
> Moffit's excellent buildscript, I also get the errors. I can also 
manually force the link with
> the correct libraries, but this is a pain. Where / How does gcc 
decide which libraries
> to use when linking ? Also if one wants to use some of the less 
common compile 
> options, that result in binary incompatibilities, how can one build 
a libgcc with the same 
> options ? e.g. if one wants to use the option -fpack-struct.
> 
> Regards
>    Anton Erasmus
> -- 
> A J Erasmus

Just had a look at the build script you are using, its not the 
process I have been using to build a cross-compiler.

My only comments are he performs a make all before he has built his c 
library (newlib), normally you need to do a make all-gcc install-gcc 
to build the bootstrap compiler then build newlib - then back to do a 
make all install.

Regards
Spen

Re: [lpc2000] Re: Newlib problem

2005-04-06 by Anton Erasmus

On 5 Apr 2005 at 22:19, ntfreak2000 wrote:

> 
> 
> --- In lpc2000@yahoogroups.com, "Anton Erasmus" <antone@s...> wrote: >
> On 5 Apr 2005 at 9:02, ntfreak2000 wrote: > > > > > > > --- In
> lpc2000@yahoogroups.com, Leonardo Santos <lsantos@p...> wrote: > > >
> Rebuilding my toolchain and searching where _udivsi3.o was compiled, >
> > I noticed > that there are four versions of libgcc.a: > > > >
> lib/gcc/arm-elf/3.4.3 > lib/gcc/arm-elf/3.4.3/thumb > > >
> lib/gcc/arm-elf/3.4.3/interwork > > >
> lib/gcc/arm-elf/3.4.3/thumb/interwork > > The first is compiled with >
> > no options. The second with -mthumb, the third with > > >
> -mthumb-interwork and the last one with -mthumb -mthumb- interwork. By
> > > using > -L to include the appropriate one (in my case, > > >
> lib/gcc/arm-elf/3.4.3/interwork), all erros went away. So sorry for >
> > raising a > flag for no reason. > Thanks a lot! > > On Monday 04
> April > > 2005 13:01, Robert Adsett wrote: > > At 12:00 PM 4/4/05
> -0300, > > Leonardo Santos wrote: > > >         First, than you all
> for the > > answers on my previous question about > > > a C union > >
> >not working > > for IO access. I'm now compiling some programs with
> GCC 3.4.3 > > > > > and newlib 1.12. I've download the source packages
> from > > > > > http://rod.info/arm.html and used his build script to
> build the > > > > > toolchain. All went very smooth. I've been able to
> compile FreeRTOS > > for > > > LPC2106 and tried to blink some LEDs >
> > >(hence the > > question about the C union), but when I try to use
> any code > > > from > > the newlib, I get the following warning: > > >
> > > >arm-elf-ld: > > Warning: /opt/arm/lib/gcc/arm-elf/3.4.3//libgcc.a
> (_udivsi3.o) > > > > >does > > >not support interworking, whereas
> test2.prg does > > > > > > It's complaining that the C compiler
> library is not compiled with > > > > internetworking.  In this case
> it's trying to link in a division > > > > routine.  Newlib does not
> provide these, they are built with gcc > > normally. > > > > Robert >
> > > > > > It sounds like you are calling ld directly on the command
> line. > > If you use gcc to perform the link then the correct libs
> will always > > be used. > > > > Unfortunately that does not appear to
> be the case. I have a similar problem in that > the correct libraries
> are not automatically being used. I am definitely linking using gcc >
> and not ld. When using the arm-elf binary toolset from
> http://www.gnuarm.com under > cygwin, my code links with the correct
> libraries. If I use the linux binaries from the same > site under RH9,
> I get similar errors. When using tools built from source using Rod >
> Moffit's excellent buildscript, I also get the errors. I can also
> manually force the link with > the correct libraries, but this is a
> pain. Where / How does gcc decide which libraries > to use when
> linking ? Also if one wants to use some of the less common compile >
> options, that result in binary incompatibilities, how can one build a
> libgcc with the same > options ? e.g. if one wants to use the option
> -fpack-struct. > > Regards >    Anton Erasmus > -- > A J Erasmus
> 
> Just had a look at the build script you are using, its not the 
> process I have been using to build a cross-compiler.
> 
> My only comments are he performs a make all before he has built his c
> library (newlib), normally you need to do a make all-gcc install-gcc
> to build the bootstrap compiler then build newlib - then back to do a
> make all install.
> 

Thanks,

I will modify the script to first build the bootstrap compiler, then newlib,
and then the final compiler. Do I need to run configure for the  compiler
again after building newlib ?

Regards
  Anton Erasmus

 
 

-- 
A J Erasmus

Re: [lpc2000] Re: Newlib problem

2005-04-06 by Leonardo Santos

Already did that. The scrips then goes like this:

  echo "($0) building botstrap GCC"
  make all-gcc install-gcc LANGUAGES="c c++"
  cerror "GCC build failed"

  mkdir -p ../${newlibbase}
  cd ../${newlibbase}

  echo "($0) configuring newlib"
  ../../source/${newlibbase}/configure \
     -v --quiet --prefix=$prefix --disable-newlib-supplied-syscalls \
     --target=${target} --enable-interwork --enable-multilib \
     --with-gnu-ld --with-gnu-as
  cerror "newlib configuration failed"

  echo "($0) building newlib"
  make all install #clean
  cerror "newlib build failed"

  cd $prefix/source
  cd ../build/${gcccore}
  echo "($0) building GCC"
  make all install LANGUAGES="c c++"
  cerror "GCC build failed"

All goes well until de final build of GCC. Then I get this error:

/opt/arm/build/gcc-3.4.3/gcc/xgcc -shared-libgcc 
-B/opt/arm/build/gcc-3.4.3/gcc/ -nostdinc++ 
-L/opt/arm/build/gcc-3.4.3/arm-elf/libstdc++-v3/src 
-L/opt/arm/build/gcc-3.4.3/arm-elf/libstdc++-v3/src/.libs 
-B/opt/arm/arm-elf/bin/ -B/opt/arm/arm-elf/lib/ 
-isystem /opt/arm/arm-elf/include -isystem /opt/arm/arm-elf/sys-include 
-Winvalid-pch -Wno-deprecated -x c++-header -g -O2 
-I/opt/arm/build/gcc-3.4.3/arm-elf/libstdc++-v3/include/arm-elf 
-I/opt/arm/build/gcc-3.4.3/arm-elf/libstdc++-v3/include 
-I/opt/arm/source/gcc-3.4.3/libstdc++-v3/libsupc++ /opt/arm/source/gcc-3.4.3/libstdc++-v3/include/stdc++.h 
-O0 -g -o ./arm-elf/bits/stdc++.h.gch/O0g; \
/opt/arm/build/gcc-3.4.3/gcc/xgcc -shared-libgcc 
-B/opt/arm/build/gcc-3.4.3/gcc/ -nostdinc++ 
-L/opt/arm/build/gcc-3.4.3/arm-elf/libstdc++-v3/src 
-L/opt/arm/build/gcc-3.4.3/arm-elf/libstdc++-v3/src/.libs 
-B/opt/arm/arm-elf/bin/ -B/opt/arm/arm-elf/lib/ 
-isystem /opt/arm/arm-elf/include -isystem /opt/arm/arm-elf/sys-include 
-Winvalid-pch -Wno-deprecated -x c++-header -g -O2 
-I/opt/arm/build/gcc-3.4.3/arm-elf/libstdc++-v3/include/arm-elf 
-I/opt/arm/build/gcc-3.4.3/arm-elf/libstdc++-v3/include 
-I/opt/arm/source/gcc-3.4.3/libstdc++-v3/libsupc++ /opt/arm/source/gcc-3.4.3/libstdc++-v3/include/stdc++.h 
-O2 -g -o ./arm-elf/bits/stdc++.h.gch/O2g;
make[1]: Leaving directory 
`/opt/arm/build/gcc-3.4.3/arm-elf/libstdc++-v3/include'
/bin/sh ../../source/gcc-3.4.3/mkinstalldirs arm-elf/libiberty ; \
rm -f arm-elf/libiberty/Makefile || : ; \
cp multilib.out arm-elf/libiberty/multilib.out
mkdir -p -- arm-elf/libiberty
Configuring in arm-elf/libiberty
cross-compiling...
/opt/arm/arm-elf/bin/ld: crt0.o: No such file: No such file or directory
collect2: ld returned 1 exit status
configure: error: unknown endianess - sorry
/opt/arm/source/gcc-3.4.3/libiberty/configure: line 3289: exit: please: 
numeric argument required
/opt/arm/source/gcc-3.4.3/libiberty/configure: line 3289: exit: please: 
numeric argument required
make: *** [configure-target-libiberty] Error 1


Any suggestions? The only difference to GNU ARM guide are the patches:

gcc-3.4.3/gcc/config/arm/t-arm-elf

-# MULTILIB_OPTIONS    += mno-thumb-interwork/mthumb-interwork
-# MULTILIB_DIRNAMES   += normal interwork
-# MULTILIB_EXCEPTIONS += *mapcs-26/*mthumb-interwork*
+MULTILIB_OPTIONS    += mno-thumb-interwork/mthumb-interwork
+MULTILIB_DIRNAMES   += normal interwork
+MULTILIB_EXCEPTIONS += *mapcs-26/*mthumb-interwork*

I've read in a number of GCC foruns that this is necessary to enable 
interworking.

The other patch is:

newlib-1.13.0/Makefile.in
-CFLAGS_FOR_TARGET = -O2 $(CFLAGS)
+CFLAGS_FOR_TARGET = -O2 $(CFLAGS) -DREENTRANT_SYSCALLS_PROVIDED 
-DNO_FLOATING_POINT -mthumb -mthumb-interwork

Which is supposed to disable floating point support and to enable thumb and 
interword in newlib.

>
> Thanks,
>
> I will modify the script to first build the bootstrap compiler, then
> newlib, and then the final compiler. Do I need to run configure for the 
> compiler again after building newlib ?
>
> Regards
>   Anton Erasmus

-- 
This is Linux country.
On a quiet night, you can hear Windows reboot.

Leonardo Pereira Santos
Engenheiro de Projetos
PD3 Tecnologia
av. Pará 330/202
(51) 3337 1237

Today Fortune tells us:
I am getting into abstract painting.  Real abstract -- no brush, no canvas,
I just think about it.  I just went to an art museum where all of the art
was done by children.  All the paintings were hung on refrigerators.
		-- Steven Wright

Re: Newlib problem

2005-04-06 by ntfreak2000

--- In lpc2000@yahoogroups.com, Leonardo Santos <lsantos@p...> wrote:
> Already did that. The scrips then goes like this:
> 
>   echo "($0) building botstrap GCC"
>   make all-gcc install-gcc LANGUAGES="c c++"
>   cerror "GCC build failed"
> 
>   mkdir -p ../${newlibbase}
>   cd ../${newlibbase}
> 
>   echo "($0) configuring newlib"
>   ../../source/${newlibbase}/configure \
>      -v --quiet --prefix=$prefix --disable-newlib-supplied-syscalls 
\
>      --target=${target} --enable-interwork --enable-multilib \
>      --with-gnu-ld --with-gnu-as
>   cerror "newlib configuration failed"
> 
>   echo "($0) building newlib"
>   make all install #clean
>   cerror "newlib build failed"
> 
>   cd $prefix/source
>   cd ../build/${gcccore}
>   echo "($0) building GCC"
>   make all install LANGUAGES="c c++"
>   cerror "GCC build failed"
> 
> All goes well until de final build of GCC. Then I get this error:
> 
> /opt/arm/build/gcc-3.4.3/gcc/xgcc -shared-libgcc 
> -B/opt/arm/build/gcc-3.4.3/gcc/ -nostdinc++ 
> -L/opt/arm/build/gcc-3.4.3/arm-elf/libstdc++-v3/src 
> -L/opt/arm/build/gcc-3.4.3/arm-elf/libstdc++-v3/src/.libs 
> -B/opt/arm/arm-elf/bin/ -B/opt/arm/arm-elf/lib/ 
> -isystem /opt/arm/arm-elf/include -isystem /opt/arm/arm-elf/sys-
include 
> -Winvalid-pch -Wno-deprecated -x c++-header -g -O2 
> -I/opt/arm/build/gcc-3.4.3/arm-elf/libstdc++-v3/include/arm-elf 
> -I/opt/arm/build/gcc-3.4.3/arm-elf/libstdc++-v3/include 
> -I/opt/arm/source/gcc-3.4.3/libstdc++-
v3/libsupc++ /opt/arm/source/gcc-3.4.3/libstdc++-v3/include/stdc++.h 
> -O0 -g -o ./arm-elf/bits/stdc++.h.gch/O0g; \
> /opt/arm/build/gcc-3.4.3/gcc/xgcc -shared-libgcc 
> -B/opt/arm/build/gcc-3.4.3/gcc/ -nostdinc++ 
> -L/opt/arm/build/gcc-3.4.3/arm-elf/libstdc++-v3/src 
> -L/opt/arm/build/gcc-3.4.3/arm-elf/libstdc++-v3/src/.libs 
> -B/opt/arm/arm-elf/bin/ -B/opt/arm/arm-elf/lib/ 
> -isystem /opt/arm/arm-elf/include -isystem /opt/arm/arm-elf/sys-
include 
> -Winvalid-pch -Wno-deprecated -x c++-header -g -O2 
> -I/opt/arm/build/gcc-3.4.3/arm-elf/libstdc++-v3/include/arm-elf 
> -I/opt/arm/build/gcc-3.4.3/arm-elf/libstdc++-v3/include 
> -I/opt/arm/source/gcc-3.4.3/libstdc++-
v3/libsupc++ /opt/arm/source/gcc-3.4.3/libstdc++-v3/include/stdc++.h 
> -O2 -g -o ./arm-elf/bits/stdc++.h.gch/O2g;
> make[1]: Leaving directory 
> `/opt/arm/build/gcc-3.4.3/arm-elf/libstdc++-v3/include'
> /bin/sh ../../source/gcc-3.4.3/mkinstalldirs arm-elf/libiberty ; \
> rm -f arm-elf/libiberty/Makefile || : ; \
> cp multilib.out arm-elf/libiberty/multilib.out
> mkdir -p -- arm-elf/libiberty
> Configuring in arm-elf/libiberty
> cross-compiling...
> /opt/arm/arm-elf/bin/ld: crt0.o: No such file: No such file or 
directory
> collect2: ld returned 1 exit status
> configure: error: unknown endianess - sorry
> /opt/arm/source/gcc-3.4.3/libiberty/configure: line 3289: exit: 
please: 
> numeric argument required
> /opt/arm/source/gcc-3.4.3/libiberty/configure: line 3289: exit: 
please: 
> numeric argument required
> make: *** [configure-target-libiberty] Error 1
> 
> 
> Any suggestions? The only difference to GNU ARM guide are the 
patches:
> 
> gcc-3.4.3/gcc/config/arm/t-arm-elf
> 
> -# MULTILIB_OPTIONS    += mno-thumb-interwork/mthumb-interwork
> -# MULTILIB_DIRNAMES   += normal interwork
> -# MULTILIB_EXCEPTIONS += *mapcs-26/*mthumb-interwork*
> +MULTILIB_OPTIONS    += mno-thumb-interwork/mthumb-interwork
> +MULTILIB_DIRNAMES   += normal interwork
> +MULTILIB_EXCEPTIONS += *mapcs-26/*mthumb-interwork*
> 
> I've read in a number of GCC foruns that this is necessary to 
enable 
> interworking.
> 
> The other patch is:
> 
> newlib-1.13.0/Makefile.in
> -CFLAGS_FOR_TARGET = -O2 $(CFLAGS)
> +CFLAGS_FOR_TARGET = -O2 $(CFLAGS) -DREENTRANT_SYSCALLS_PROVIDED 
> -DNO_FLOATING_POINT -mthumb -mthumb-interwork
> 
> Which is supposed to disable floating point support and to enable 
thumb and 
> interword in newlib.
> 
> >
> > Thanks,
> >
> > I will modify the script to first build the bootstrap compiler, 
then
> > newlib, and then the final compiler. Do I need to run configure 
for the 
> > compiler again after building newlib ?
> >
> > Regards
> >   Anton Erasmus
> 
> -- 
> This is Linux country.
> On a quiet night, you can hear Windows reboot.
> 
> Leonardo Pereira Santos
> Engenheiro de Projetos
> PD3 Tecnologia
> av. Pará 330/202
> (51) 3337 1237
> 
> Today Fortune tells us:
> I am getting into abstract painting.  Real abstract -- no brush, no 
canvas,
> I just think about it.  I just went to an art museum where all of 
the art
> was done by children.  All the paintings were hung on refrigerators.
> 		-- Steven Wright

Strange, I have given the configure options I always use - never 
tried script so cannot verify.

** gcc build **
./configure --target=arm-elf --prefix=/sarm-elf --enable-interwork --
enable-multilib --disable-nls --disable-win32-registry --disable-
shared --enable-languages="c,c++" --with-newlib --with-headers=/sarm-
build/newlib-1.13.0/newlib/libc/include
make all-gcc install-gcc 2>&1 | tee make-gcc.log

** newlib **
./configure --target=arm-elf --prefix=/sarm-elf --enable-interwork --
enable-multilib --disable-nls --disable-win32-registry --disable-
shared --enable-target-optspace=yes
make all install 2>&1 | tee make.log

** gcc full build **
make all install 2>&1 | tee make.log

Hope it helps.

Regards
Spen

Move to quarantaine

This moves the raw source file on disk only. The archive index is not changed automatically, so you still need to run a manual refresh afterward.