Re: Libgcc symbols

[Phil Edwards <pedwards@disaster.jaj.com>]

On Mon, Apr 16, 2001 at 09:08:22AM -0700, Zack Weinberg wrote:
> #ifdef L__dummy
> void
> __dummy (void) {}
> #endif
> 
> Referenced nowhere, but I'd like to know why it was added in the first
> place before killing it.

I don't know, but I've seen something very similar in a much less complex
project.  A static library of makeup/replacement routines was being created,
but the list of routines (and thus the list of .o files) could conceivably
be empty, causing grief for 'ar'.  A dummy .o was always created just to
ensure that 'ar' would also have at least one object file to work with.

I can't imagine all of the routines in LIB2FUNCS not being necessary,
so the __dummy here is probably for some other purpose than my example.


> Why we still have libio in-tree at all is another question.  (I have
> never understood why iostreams aren't a layer of paint on top of
> the public stdio interface.)

Right now, it is.  Which is a pity, because it's another layer of buffering
and function calls.  Efficiency drops considerably on some platforms when
iostreams has to funnel everything through stdio.

Ideally, we'd like the C and C++ I/O pieces to each go directly to some
common underlying layer that's as thin as possible.  When we're building on,
say, glibc 2.2 platforms, we detect that the underlying layers are already
"out there" and ignore the in-tree version.  Otherwise we build our own.

This ran into problems a while back and was disabled by default.


Phil

-- 
pedwards at disaster dot jaj dot com  |  pme at sources dot redhat dot com
devphil at several other less interesting addresses in various dot domains
The gods do not protect fools.  Fools are protected by more capable fools.