Re: Several glibc problems...
On Mon, Nov 16, 1998 at 01:09:38PM -0500, Dale Scheetz wrote:
> It is time to get all of the developers involved in the several glibc
> problems that I have been unable to grapple with.
>
> 1. glibc 2.0.7
> 2. glibc 2.1
> 3. kernel headers
>
> 1. glibc 2.0.7
>
> At this point there is little "real" work being done on the 2.0 code. All
> of the work is being done on the 2.1 release instead. This leaves me
> between a rock and a hard place.
>
> 2. glibc 2.1
>
> I have been working on a package for this release for about two months
> now, with varying degrees of success. This library is greatly modified
> from the 2.0 version, even though many things have been back ported. I
> have been able to build it with the 2.0.32 kernel headers we have been
> using for 2.0.7, and although it seems to build without problems, I
> suspect that there will be problems associated with not having a new
> enough kernel header package.
What I would like to see is a version of glibc 2.1 compiled for
experimental, for now. It will probably need a matching libstdc++ (not
sure if this applies to x86, but they are very picky about matching
libc exactly, even between 2.0.95 and 2.0.100).
> 3. kernel headers
>
> The sparc ports, along with several other of the ports (maybe all?) are
> using kernels from the 2.1 development tree. As a result they are also
> using 2.1 glibc pre-releases. The upstream maintainers of glibc are also
> mostly working with the 2.1 kernels in their development, so this is a
> reasonable thing to do. For the intel release, however, we have never used
> a "development" kernel in a release, so from my position, this transition
> is ... well, difficult.
PowerPC certainly is; a lot of the other ports have a choice between a
lightly patched 2.1.x and a very heavily patched 2.0.x kernel. glibc
2.1 however is much pickier. Does a glibc compiled on 2.1.x headers
run on 2.0.3x?
> Should we consider producing a release with a "development" kernel?
Preferably, we should have a 2.1.x kernel and pre2.1 glibc packaged for
i386, but not released. When 2.1 stabilizes - hopefully in December
- and 2.2 kernel is released (who knows when), we'd be ready.
> Should I target such glibc packages for experimental only?
For x86...probably, yes. Be sure to coordinate with the various people
doing libstdc++ uploads, so that we can have one in experimental linked
to this libc. The transition, while not as bad as libc5->libc6, is a
big one; binaries compiled on glibc 2.1 will not run on 2.0 for many
more reasons than compiler mismatches.
On a vaguely related note, Dale, have you considered Joel Klecker's
glibc-maint proposal? Asking one man to shoulder the burden for all
ports doesn't make a great deal of sense, IMO.
Dan
Reply to: