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

Gerard Beekmans gerard at linuxfromscratch.org
Tue Sep 5 10:16:45 PDT 2000


> NOTES:
>   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 you 
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 forget 
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 linked 
against libc5

It's not a matter of configure&&make&&make install on the static versions when 
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 
(linuxfromscratch.org was hosted on that system if I'm not mistaken). But 
Paul's not on this mailinglist anymore and pcrdallas.com is down so I don't 
even know if he wrote an lfs-hint for this (I'm still waiting for Simon to get 
back to me on the lfs-hints matter). You could try to email him personally and 
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 definition 
of something. This is a known problem on some packages when linked statically 
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 name 
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:
#!/bin/sh
#begin

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

Of course, add all the variable names to the 'i' variable in that script. Save 
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
www.linuxfromscratch.org

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





More information about the lfs-dev mailing list