Can't get past Bzip2

Barry barry at
Thu Dec 28 08:57:04 PST 2000

WarmFuzzy wrote:
> barry at wrote:
> > First, though...  a question...
> >
> > what version of glibc does Mandrake 7.2 use?
> >
> > this can be attained with the command:
> >
> >         strings /lib/libc* | grep "release version"
> >
> > this command comes from the glibc install routine in the LFS book.
> >
> > if it uses the gcc 2.2 pre-release version, then you will likely have
> > trouble compiling gcc 2.95.2 with it, amongst other programs.
> It says:
> GNU C Library stable release version 2.1.3, by Roland McGrath et al.
> Hugo

OK, good...

it's the stable version, then...

I'd suggest that if further builds of bzip2 statically fail, that you
try to compile and use gcc-2.95.2 on your own system (procedure is just
before the gcc install on the LFS system in the LFS book) and try to use
that to compile packages from now on...particularly if you're getting
problems compiling some of the base packages like binutils.  Of course,
you could also try to compile the bzip2 program in the chroot'ed
environment.  Just don't forget to untar the source archive on the LFS
partition before you enter the chroot'ed environment, also - don't use
the tar patch with support for bzip2 when doing the static build.  Once
you have bzip2 built, then untar the archives using:

bzcat <archivefile.tar.bz2> | tar xv

that will produce your archive directory until you've recompiled tar
with support for bzip2.  I want to add that I've never tried this, but
it should work.  And also, this is assuming that the only package which
is having compilation problems is bzip2, which may not be the case.  A
trick that I use is that I type 'echo $?' after completing the
../configure, make, make install sequences for the packages.  Make is
written in such a way that compile problems will be reported back to the

if you type 'echo $?' after the ./configure && make && make install
sequence, then it will return either 0 if the compile and installation
was successful, otherwise it will return another number if it failed. 
This number may be different depending on why the sequence failed.  The
shell variable $? in bash holds the return code of the last executed
command.  See the bash manual for more details, but if you type 'cho $?'
then try to correct your mistake by typing 'echo $?'  it will return a 1
because the last command through that shell was the botched echo
command.  This has happened to me a number of times :)

Another error auditing mechanism which is similar to this might take the
form of ./configure && make && make install && echo 'Completed
Successfully' || echo 'Sequence Failed'

this should be fairly self explanatory.  I added the above because I
recall that you weren't sure if the binutils compile was successful or
not.  I usually use any of the above techniques if I'm at all dubious on
the situation.

Also, check the mandrake distro for another gcc package.  It's possible
that they pulled a Red Hat and included the stable gcc in another

good luck :)

Unsubscribe: send email to lfs-discuss-request at
and put unsubscribe in the subject header of the message

More information about the lfs-dev mailing list