Re: What to put in a shared libgcc

[Geoff Keating <geoffk at cygnus dot com>]

> From: Mark Kettenis <kettenis@wins.uva.nl>
> Date: Tue, 11 Jul 2000 19:40:55 +0200

> I left out the arithmetic support functions (such as __ashldi3,
> __floatdixf, etc.).  These can go anywhere we like.  That probably
> means keeping them in the libgcc archive, provided we can address the
> problem of reexporting themfrom shared libraries created with GCC,
> which at least on Linux, I think we can.

Actually, it'd probably be better to put them in the shared library,
because they have very stable interfaces and because this solves the
reexport problem.

You can't just make all future shared libraries not export these
functions, because some existing shared libraries do export them and
you would break any applications linked to those libraries.  The
functions have to be around somewhere.

...
> frame.o:
...
> I'm a bit worried though about the fact that this program references
> pthreads functions.  This means that changing the ABI for these
> functions in libc might have disastrous consequences.  And since
> pthread_mutex_t isn't an opaque type, and might need to be extended to
> support new mutex attributes, changing the ABI may become necessary.
> Perhaps we should formalize an alternative interface for a basic mutex
> type in glibc such that libgcc can use that instead?

Note that the pthreads referencing depends on how gcc is configured.
A common trap on linux systems is to forget to build gcc with threads
enabled and then discover that the libc you build with your new gcc
doesn't work.

-- 
- Geoffrey Keating <geoffk@cygnus.com>