glibc-2.3.4-20040701: error with libc_pic.a

Matthew Burgess matthew at linuxfromscratch.org
Thu Dec 30 03:39:41 PST 2004


Andrei A. Voropaev wrote:
> On Thu, Dec 30, 2004 at 03:16:05AM -0800, Jeremy Utley wrote:
> 
>>Andrei A. Voropaev wrote:
>>
>>
>>>On Thu, Dec 30, 2004 at 02:54:03AM -0800, Jeremy Utley wrote:
>>>
>>>
>>>
>>>>Andrei A. Voropaev wrote:
>>>>  
>>>>
>>>>
>>>>>Downgrade binutils. I had exactly the same problem. Finally, I gave up
>>>>>and used binutils-2.15 and immidiately everything started to work.
>>>>>
>>>>>    
>>>>>
>>>>
>>>>DO NOT downgrade binutils!  Binutils versions prior to 2.15.94.0.2 are 
>>>>what causes this in the first place!  Try building your initial binutils 
>>>>and gcc's dynamic instead of static and see what happens.
>>>>  
>>>>
>>>
>>>Well. YMMV. In my case it resolved all problems.
>>>
>>
>>But, you're susceptible to the problem again now that your binutils 
>>doesn't have the stripping problem fixed.  Your current libc.a is going 
>>to be missing the TLS symbols.
> 
> 
> 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.

LFS systems themselves are fine, as long as you either a) use the latest 
version of binutils or b) don't strip libc.a.

Cheers,

Matt.



More information about the lfs-support mailing list