glibc-2.3.4-20040701: error with libc_pic.a
Andrei A. Voropaev
av at simcon-mt.com
Thu Dec 30 03:48:51 PST 2004
On Thu, Dec 30, 2004 at 11:39:41AM +0000, Matthew Burgess wrote:
> >Ok. I'll keep in mind that building statical version of programs might
> >fail for this reason. Since I don't do it normally I should be safe for
> >most of the time. (Unless there's something else). But I had only 2
> >alternatives: either to have the system with that problem, or not to
> >have the system at all. Because it looks like a chicken and egg problem.
> >If I compile new binutils with old library, then they are broken and
> >won't compile new library. And if I compile new library with old binutils,
> >then I have broken library again :)
> Just to clarify. The problem is with your host system. Basically
> Suse-9.1 stripped its libc.a with a buggy version of binutils so the TLS
> symbol type information disappeared. This is irreparable, save using a
> different host, or somehow upgrading/fixing your host's glibc.
Hm. Just to clarify :) I'm not the original poster, and I didn't use
Suse. I was booting with Knoppix CD. More importantly. I've managed to
install glibc into /tools directory. So, I guess, there it was not
stripped. (But I had to compile it with binutils-2.15). After installing
glibc I've installed newer version of binutils in tools directory. So in
chapter 6 I was already compiling new glibc with new binutils and was
not using stripped libc.a. But the problem didn't go away.
> LFS systems themselves are fine, as long as you either a) use the latest
> version of binutils or b) don't strip libc.a.
So I feel, that the statement above is not 100% correct. The problem is
somewhere else, and not in some stripped version of libc.a
Minds, like parachutes, function best when open
More information about the lfs-support