[uClibc]Re: [BusyBox] tar and getopt (again)

[Erik Andersen]

On Mon Jan 22, 2001 at 05:33:11PM -0600, Manuel Novoa III wrote:
> Erik,
> 
> > > (stuff I wrote about grabing funcs for libgcc.a)
> > I suppose that is ok.  The real problem is knowing apriori which functions
> > we need, since it will change per platform.  I suppose we could hack up
> > the makefile to check which arch we are building for.
> 
> You might have missed the message this weekend so here's part:
> -------------------------------------------------------
> Erik, I just verified that this approach works fine.  A small modification to
> the main Makefile should do it.  Something in the shared lib section like
> @(cd tmp ; ar -x  `gcc -print-libgcc-file-name` _umoddi3.o _udivdi3.o)
> but this should be arch-dependent.  Other archs my require other object files
> as well.  What do you get for arm if in the uClibc dir you do
> 
> mkdir tmp
> cd tmp
> ar -x ../libc.a
> ld -r -o test *.o ../crt0.o
> nm -s test | grep " U " | grep -v " main$"
> -------------------------------------------------------

Yup, seems I missed it sorry.

[andersen at winder tmp]$ cat /proc/cpuinfo
Processor       : Intel StrongARM-110 rev 3 (v4l)
BogoMIPS        : 262.14
Hardware        : Rebel-NetWinder
Revision        : 44ff
Serial          : 0000000000000639
[andersen at winder tmp]$ nm -s test | grep " U " | grep -v " main$"
         U __divsi3
         U __modsi3
         U __muldi3
         U __udivdi3
         U __udivsi3
         U __umoddi3
         U __umodsi3

> We should just be able to automate something like this to grab the appropriate
> symbols.  After all, the only things that should be undefined in libc.a are
> main and anything that gcc threw in from libgcc.a.

Excellent suggestion.  Yes, we do want to do this.

 -Erik

--
Erik B. Andersen   email:  andersen at lineo.com
--This message was written using 73% post-consumer electrons--