Date: Mon, 31 Jul 2000 13:52:19 +0200
From: Marcus Brinkmann <[EMAIL PROTECTED]>
I don't think you really keep track of the Debian build scripts, do
you? :) (Ben Collins takes over maintenance of glibc, and he asked
me to take a look at his pre-packages).
No, I still live in the dark ages where you'd get the source as a tar
file and compile it yourself :-).
> Just a warning: I recently made some changes to the Hurd's Makefiles
> that reorder some libraries. An older Hurd (i.e. one that doesn't
> have those patches) won't work with glibc 2.2.
You mean it won't run? So the Hurd needs to be recompiled and both
have to be installed updated at the same time? (This probably needs
to be reflected in the package dependencies).
A Hurd compiled from sources dating before 2000-07-26 won't run with
glibc 2.2. Everything after that date should work with both glibc 2.1
or glibc 2.2. They do not have to be upgraded at the same time.
People can upgrade their Hurd now (well, when there's a new Debian
package).
Compiling the Hurd with the glibc 2.2 headers doesn't quite work yet.
libshouldbeinlibc/wire.c depends on some dynamic linker internals that
have changed and are no longer exported. One of the things that I'll
have to fixed before glibc 2.2 is released.
> I got the following error. Is this related to cross compilation? Will
using
> glibc2.2 on linux help?
>
> It's hard to say. Compiling glibc from CVS usually works for me,
> although there's a minor glitch from time to time.
>
> The undefined references come from the dynamic linker (ld.so). It
> looks as if the build process is using the old ld.so instead of the
> new one.
It can't use the new linker when cross compiling, right?
Well, it cannot actualy *execute* a program when cross compiling. But
when building glibc the static linker should look at the new ld.so
instead of the old ld.so. You know, ld.so is not only the program
interpreter, but it also is a shared library.
Anyway, either something went wrong with your build (nm and objdump
might be handy to find out what's wrong), or your cross compiler is
screwed somehow (passing -v to gcc can be of assistence here).
Mark
