[uClibc]Re: a couple of fixes

Erik Andersen andersen at lineo.com
Sun Jan 14 09:42:25 UTC 2001


On Sat Jan 13, 2001 at 07:51:47PM -0600, Manuel Novoa III wrote:
> Erik,
> 
> On Sat, 13 Jan 2001, Erik Andersen wrote:
> > The reason I started using _start.S and linking it into the lib directly was it
> > seemed painful to always link in crt0.  With the addition of gcc-uClibc it is
> > much less painful now.  I am wondering, maybe we should go back to the standard
> > method of providing a separate crt0 lib.  Thoughts?
> 
> I think using crt0 across archs is a good idea.

I agree.  I will update my tree with the name change.

BTW, re getting cvs commit priviledges -- If you visit 
    http://cvs.uclinux.org/cvs_write.html
and follow the directions I'll get you set up asap.

> On the cross-arch front, it doesn't appear that weak symbols are available in
> James Graves' environment.  I hate to give them up on i386 since they're so
> convenient.  The best alternative I've come up with so far is to provide almost
> empty object files which could be linked before the library.  For example, an
> object file called something like omit_stdio.o could provide an empty
> __init_stdio function, and could be linked before the library to avoid pulling
> in the unused stdio code.  This could be done in conjuction with some
> gcc-uClibc options to make the process easier -- say gcc-uClibc --no-stdio.
> What do you think?  I'd still like to keep the weak symbol stuff where it is
> supported.

I see -- so we would basically use ar to create a sort of fake weak-symbol
support, since it will overwrite older objects with the same name.  So for
arches lacking weak symbols, we simply include extra code into sysdeps/arch/foo
to replace the weak-symbol-ified junk, and make sure sysdeps is compiled/added
to libc.a last.  That is twisted, evil, and wrong.  I like it.  :-)

> One unrelated question -- do you think there is any reason to keep
> sys_errlist[] as is?  Right now it is about 3.7k.  With a mini-sized
> compression scheme, I think I can shave from 1.5k to 2k off of the necessary
> data storage and still implement strerror.c.  But sys_errlist[] would go away. 
> Comments?  I suppose we could do both and allow a choice.

Hmm.  We do lose some compatibility here.  There are a number of (admittedly
misguided) app that use sys_errlist[] directly.  Of course, if we throw out
compatibility with broken apps, we can move this crap so it it read in from a
text file in a known filesystem location, causing only one copy to need to
exist per system.  Hmm.  That won't be all that helpful when we get shared libs
though, since we will only need one copy then too... 

So this is certainly worth further thought -- but I'm not ready to change it
quite yet.  

 -Erik

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





More information about the uClibc mailing list