Problem using newly compiled static binutils for any packages mak ing use of regular expressions

John Arrowwood John.Arrowwood at
Tue Sep 5 15:37:26 PDT 2000

Yes, I checked.  If I take the new ld out of the path, it works.  I
specifically logged OUT of the shell after installing binutils, then logged
back in and modified the path before moving on to the next package.  I
didn't know about hash -r...  I will make use of that from now on, instead,

But what I didn't realize is that my glibc is old...too old.  I will try
installing and making use of the new glibc as early in the install process
as possible and see if that solves the problem.  I will let you know.

-----Original Message-----
From: Gerard Beekmans [mailto:gerard at]
Sent: Tuesday, September 05, 2000 10:17 AM
To: lfs-discuss at
Subject: Re: Problem using newly compiled static binutils for any
packages mak ing use of regular expressions

>   1) binutils have been compiled statically, and installed to
> $LFS/usr/local/temp
>   2) /usr/local/temp is sym-linked to point to $LFS/usr/local/temp
>   3) the path has been modified so that /usr/local/temp/bin is first
>   4) THEREFORE: When using "ld," it is using the version in
> $LFS/usr/local/temp/bin, not /bin

You are sure of that. Have you taken bash' hash function into account? If
have executed 'ld' at least once in that particular shell before you updated

the path, bash will still use ld in the first found path. To make bash
about this hash database run: hash -r

To find out if a command is hash'ed or not execute:
	type ld
If it's not hashed (when this shell executes ld for the first time):
	ld is /usr/bin/ld
If it is:
	ld is hashed (/usr/bin/ld)

Just something you might want to look into. It can cause nasty problems if 
you're not expecting it.

Ok I'm a bit confused here so let me try to recap a few things:

1) you have installed binutils statically in $LFS/usr/local/temp
2) on your normal system (so outside chroot) you have modified your path to 
have $LFS/usr/local/temp/bin appear as the first directory, thus you use 
binutils-2.10 on your normal system (outside chroot)
3) you are compiling fileutils statically using the 2.10 version on binutils
4) because you're linking statically and outside chroot, fileutils are
against libc5

It's not a matter of configure&&make&&make install on the static versions
your base system uses libc5 (the book makes a reference that libc5 isn't 
supported, but it's not impossible though).

I know Paul Jensen has installed an LFS-1.3 system a long time ago where the

normal system used libc5. He had some problems but he got it running 
( was hosted on that system if I'm not mistaken). But 
Paul's not on this mailinglist anymore and is down so I don't 
even know if he wrote an lfs-hint for this (I'm still waiting for Simon to
back to me on the lfs-hints matter). You could try to email him personally
see if he can give some help. 

Though firstly you might want to try this:
All your errors (or at least most of them) relate to some multiple
of something. This is a known problem on some packages when linked
against some glibc version (in fact, the regex code on gnu utils is almost 
always directly copied from the glibc source which results in variable 
colissiosn when linked statically - there are two variables with the same
in the same name space - that's illegal).

So what you can try is rename all those instances of re_search_2, 
re_set_registers, re_compile and all the others in something else, like 
re_search_2-2 and re_set_registers-2 and re_compile-2 and so forth.

This can be done with a simple script that uses sed:

for i in re_search_2 re_set_registers re_compile
	sed s/$i/$i-2/ regex.c >out
	mv out regex.c
	sed s/$i/$i-2/ regex.h >out
	mv out regex.h

Of course, add all the variable names to the 'i' variable in that script.
it, chmod 755 it, execute it and try to compile. You probably have to change

variables in others places as well but follow the same strategy. I hope that

this works for you.

Gerard Beekmans

-*- If Linux doesn't have the solution, you have the wrong problem -*-

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the lfs-dev mailing list