This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: A shared version of libgcc
> Wouldn't it be a great win if we could avoid linking with the shared
> libgcc.so for ordinary C code?
Why would that be a great win?
> The idea is that once the Kernel people get their act together, and
> provide sane support for threads in the Linux kernel, we'll want to
> write a pthreads library that takes advantage of this. It will be
> hard to do this while keeping the ABI compatible with the current
> implementation.
Why is that? libgcc only use the standard API (i.e. Posix threads) to
access the thread library. Why would you expect to break this? Which
specific function currently used by libgcc would you expect to break
on a binary level?
And when you do break this function, how would you deal with the large
number of applications that are linked with pthreads?
> Also note that if you link libc with the shared libgcc and that
> libgcc is tied to a specific pthreads implementation, you
> effectively tie libc to that specific pthreads implementation.
Isn't libc already tied to a specific implementation of pthreads? It
uses it for thread-safe IO and memory allocation, and therefore
contains a large number of pthread_mutex_t objects.
> Of course there are ways to work around this in libgcc or in libc.
> But we should investigate this now, before introducing a shared
> libgcc and create a situation we later regret.
How exactly would you investigate that?
> This makes moving binaries created with GCC 3.0 to a system where libc
> wasn't built with GCC 3.0 extremely painfull. Even if you install the
> right libgcc.so, things might not work, unless you link the program
> explicitly against libgcc.so (otherwise the dependency on libgcc.so
> isn't recorded).
I'd expect that gcc 3 links all applications and shared libraries with
libgcc implicitly, just as gcc 2 does. Why would that produce a problem?
Regards,
Martin