Re: The libgcc.so for glibc initiative

["H . J . Lu" <hjl at lucon dot org>]

On Thu, Jul 13, 2000 at 01:12:22PM +0200, Mark Kettenis wrote:
>    Date: Wed, 12 Jul 2000 23:04:17 -0700
>    From: "H . J . Lu" <hjl@lucon.org>
> 
>    Hi, Folks,
> 
>    Given the current libgcc.so situation, I'd like to start the libgcc.so
>    for glibc project. The goals are
> 
>    1. Binary compatible with binaries linked with glibc 2.0, 2.1, 2.2 and
>    above.
>    2. Stand alone as well as glibc add-on.
>    3. Can be used to upgrade libgcc.so from an installed gcc.
>    4. Support glibc and glibc only.
>    5. Support glibc 2.2 and above.
>    6. Support gcc 2.96 and above.
> 
>    It can be hosted on sourceforge or under glibc like linuxthreads. Any
>    comments?
> 
> There's nothing against experimenting with this, and using it as a
> temporary solution util the libgcc.so thing settles down a bit.

I am just to be realistic. There is no way I can see that gcc can
provide a general solution for libgcc.so on all targets it supports.
It will require the runtime support from the system vendors. I don't
believe gcc can do it on itself. The end result may be a solution
which sort of works, but falls far short for glibc.

> However, presenting this somehow as thee official libgcc.so for glibc"
> is completely stupid.  That would only piss of the GCC team, and since

If getting a reasonable libgcc.so solution for glibc means pisses of
someone from the GCC team, there is nothing I can do about it.

> it's essential that we work with the GCC team on this thing (since
> they will still have control over the bits of code included in libgcc,
> and hence control huge parts of the ABI) this wouldn't be a terrible
> good idea.  In other words, there can be no stable libgcc.so ABI if
> the GCC team doesn't agree on it.

I guess we have to yell at them when they break the ABI. That is what
I did when they broke it on June 25.. Most of the gcc people never
maintined a system runtime shared library before. They have no idea
what takes to get things done. They should have listened to people who
have done it, including Mark from IBM. Thanks Mark.

> 
> If this ever does become the official libgcc.so for glibc thing
> 
>    6. Support gcc 2.96 and above.
> 
> should become
> 
>    6. Support gcc 3.0 and above.
> 
> Since we shouldn't officially support an unreleased version of GCC.
> Of course we'll have a --i-really-want-to-use-and-experimental-gcc
> option, that makes it possible to create a libgcc.so from an
> experimental GCC (such as 2.96 right now) for testing purposes.

That is what I meant.

> 
> Mark
> 
> PS Personally I still think that the GCC team should do the
> libgcc.so.  They control the interfaces.  If they cannot keep the

The problem is they don't know to do it right. They may screw things
up before we know it. I don't think glibc can afford it.

> interfaces (reasonably) stable this whole thing is doomed anyway.

That is the only thing I want from them.

> This really is a much greater challange than the simple technicalities

I know. I want to add another one which may interfere the stable ABI
since they want to get libgcc.so to work on all taregts.

> required for successfully building and installing the libgcc.so.

It is relatively trivial to support libgcc.so on glibc 2.2 since we
control everything from as, ld to glibc. We have symbol versioning as
well as working ELF visibility support in ld and ld.so. I said it only
supported glibc 2.2. Try it on Solaris. If it is that simple, I will
let gcc do it. They want a general soltion for libc 5, glibc 2.0, glibc
2.1, .......... I don't think the soltion they choose will work for
us. The best thing which can happen may be gcc will do

install.libgcc.so:
	if [ -x ...../upgrade.libgcc.so ]; then \
		CC=...../bin/gcc ...../upgrade.libgcc.so; \
	else \
		install their own libgcc.so; \
	fi

But we have to make sure ...../upgrade.libgcc.so does the right thing
first.


H.J.