glibc-2.3.4-20040701: error with libc_pic.a

Andrei A. Voropaev av at
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 mailing list