Re: Several glibc problems...
Dale Scheetz wrote:
>
> 1. glibc 2.0.7
>
> The major problem here is that there has yet to be an actual upstream
> release of 2.0.7. Altough I was promised a release soon after the Debian
> release of 2.0.7r, we are up to u, and the upstream source for that
> release was called 2.0.7pre6. During this "progress" from r to u, many
> patches were incorporated from the 2.1 development tree. Some of these
> created changes in the interface to 2.0.7 which should have generated a
> complete new point release, without such an increase in the "version"
> number.
Last I heard 2.0.7final was being held up only by an obscure dynamic linker
bug.
If you're referring to the __register_frame_info problem, that's a real bug
for which I sent Ulrich a patch last night. I'm not certain the patch is
the Right Thing - the root cause smells like a linker issue - but it does
fix the bug. I'll send you the patch separately.
It may be necessary to recompile programs compiled against 2.0.7u once the
patch is applied, but I think it isn't.
Are there any other incompatibilities between 2.0.7t and 2.0.7u?
> 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.
The release of 2.1final is going to be delayed until after the 2.2 kernel
release. Also, there's a C9x committee meeting soon at which they may
redesign the time functions again, so we're waiting on that too. Other than
that, the code is frozen.
In theory, the only problem with building 2.1 libc against 2.0 kernel
headers is that it won't be aware of 2.1 kernel features. See below.
There are hairy interaction issues between glibc and libstdc++. In
particular, you should compile them with the same compiler (egcs-1.1[.1]
preferably), and you need to rebuild libstdc++ if you change libc from 2.0
to 2.1 (this is the ONLY library that should need that). Also, there were
C++ related bugs fixed in the binutils 2.9.1.0.x series, it may be a good
idea to update binutils from 2.9.1 to 2.9.1.0.16.
> 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.
The deal is this. If you compile glibc (2.0 or 2.1) against 2.1 kernel
headers, it is made aware of 2.1 kernel features. Wrappers are generated
for 2.1-only system calls, some functions attempt to use 2.1 interfaces
internally. In all cases, the library detects at runtime if a 2.0 kernel is
in use, and falls back sanely. You might see 'unimplemented syscall' log
messages on some platforms (Alpha?), but everything continues to work.
Once the library is compiled and installed, it doesn't care which kernel
headers appear in /usr/include/linux and /usr/include/asm. It'd be
perfectly legitimate to keep those at 2.0.32 and still compile the library
with 2.1 headers. Programs that reference <linux/foo.h> directly may have
problems but we've been saying not to do that for ages now.
We (upstream) say you should always use 2.1 headers to compile libc 2.0 and
2.1 because then you won't have to rebuild libc if you decide to try a 2.1
kernel. The --with-headers configure switch (only in libc 2.1 I think)
allows you to do that without changing /usr/include. The source package
could have a copy of the kernel headers in a private location, refer to them
during the build, and then throw them away. Just make sure you run 'make
config' on the kernel tree before copying its headers (otherwise
linux/version.h doesn't exist), and change the asm->asm-xyz link for the
architecture in debian/rules before running configure.
The precise version of the kernel headers doesn't matter as long as you use
a sufficiently recent one. I think the last change that mattered was in the
2.1.9x series, but I could be wrong.
zw
p.s. I use Debian myself and would be willing to help with any problems you
have with libc.
Reply to: