Re: My proposal for the libgcc runtime ABI (ia64 gcc/glibc is broken.)

[Ulrich Drepper <drepper at redhat dot com>]

Jeffrey A Law <law@cygnus.com> writes:

> Yes, I'd forgotton about that.  It's one of the issues that needs to
> be addressed.  However, I'm not going to say "must never", just that it's
> an issues that must be resolved in one way or another.

Every application will be linked against this library and therefore it
must be available on the root filesystem where there is certainly no
room for gcc.

> But we need to -- we're not just building a linux compiler.  We need this
> capability across a number of systems to resolve a number of nasty problems.

We don't have to care about these things on other platforms (perhaps
on BSD but these people do their own stuff anyway).  The problem only
exists if the libc is using the code from libgcc and possibly
re-exports it.

> Some native systems have multilibs.  alphas for example, maybe sparcs.
> And in the embedded linux world we will likely have systems that need
> multilibs.  We can't simply ignore those issues.

None of the systems we care about.

> Multilibs are very interesting, and I don't think it's a given that the
> install directory will be /lib.  I believe that is still subject to debate.

We are completely missing each other.  You completely underestimate
the work needed to keep this compatibility library up-to-date.
Putting this in gcc means you cannot make a new release of gcc until
every single platform is handled (means, you have to actually review
all the interfaces for each OS/arch combination).  If nobody is
volunteering you have to do it yourself since otherwise you'll put out
a gcc version which can create incompatible binaries or breaks
existing one.  This is wrong.

Doing things outside gcc has the advantage of not delaying the
release.  The worst case is that the new release cannot be used on a
certain platform but that's it.  And this would be the fault of the
people writing the libgcc.so for that arch/OS.

It will also be up to the arch/OS groups to decide when binary
compatibility is dropped and all compatibility stuff from libgcc.so
should be dropped.

In the end you might end up to have an individual configuration for
each arch/OS/host/target combination.  I don't believe for a second
that you can centrally manage this.


I don't know how to make this clearer, libgcc.so is a system library.
Unless you want to get into the system library development you should
not even consider handling the libgcc.so yourself.

Besides, I have not heard a single convincing argument why libgcc.so
should be generate as part of gcc.  What do you want to achieve?

-- 
---------------.                          ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \    ,-------------------'   \  Sunnyvale, CA 94089 USA
Red Hat          `--' drepper at redhat.com   `------------------------