[uClibc]Re: Quick question -- please reply soon.

[Erik Andersen]

On Fri Jan 05, 2001 at 12:37:26PM -0600, Manuel Novoa III wrote:
> 
> Erik,
> 
> I've been consolidating things to submit for uClibc, but I need to know
> something first.  I'm assuming gnu tools for working with uClibc and have

First of all, since I think this is of general interest, I'm CC-ing the mailing
list.  I hope you don't mind...

Assuming GNU tool chains is valid.  Any fool wanting to use MS Visual C++ or
MetroWorks or whatever will lose.  We want to be able to use GNU-isms such as
__attribute__.  So far so good. 

> started using weak symbols in some places.  In particular, I'm using them
> to handle stdio initialization only if stdio is needed, and I'm using them now
> to link in gnu getopt (with long options) in place of uClibc getopt only if
> long options are needed (for example busybox getopt).

Ahh.  This does sound like a safe, sane approach (avoiding putting calls
to the slow init code in each and every stdio function).
all the init

I'm guessing you saw the web page I put up and got concerned, right?
    http://cvs.uclinux.org/uClibc.html

> I need to know:
> 1) Is the use of weak symbols a problem?
> 2) If not, what is your preferred method of using them?

Well, they do have some advantages (as you have noted) but there is a price to
be paid (see http://www.bitwagon.com/elfvector.html for some discussion on this
subject).  Furthermore, I plan on making full shared library support not just
on x86, but also on MMU-less systems.  I have some ideas on how this can be
done (a full blown discussion on this topic is invited some time).  

I've been working on the assumption that supporting weak symbols in that case
wouldn't work, but as I think about it, I suppose those could be supported too.
It just requires more code.

Any thoughts?  I'm open to allowing them or ruling them out.  Generally as I've
gone through the code (esp code stolen from glibc) I've been throwing them out
since they were, in nearly all cases, being overused/abused...

> As an example for #2, in getopt.c I'm doing
> 
>   int opterr __attribute__ ((__weak__)) = 1; /* error => print message */
>   int optind __attribute__ ((__weak__)) = 1; /* next argv[] index */
>   int optopt __attribute__ ((__weak__)) = 1; /* Set for unknown arguments */
>   char *optarg __attribute__ ((__weak__)) = NULL;	/* option parameter if any */
> 
>   extern int getopt (int argc, char *const *argv, const char *optstring)
> 	 __attribute__ ((__weak__));
> 
> but this could also be done with pragmas with gnu-stabs.h.

No need to change.  If we decide to keep using weak symbols, then we will only
use the __attribute__ for all C code, and ".weak foo" in asm (which we do not
approve of but tolerate when we must).  pragmas are nasty.

 -Erik

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