Yahoo Groups archive

Lpc2000

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

Message

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

Attachments

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.