Red Hat 7.0

Barry Barry at
Thu Nov 9 18:17:09 PST 2000

OK, after some testing, I've found that the patches that Fred Anger gave
us do work with Red Hat 7.0...

however -

I'm a little bit dubious about those failed HUNKS from the patch.  It
looks like a conciderable amount of the patch was rejected.  I suspect
that this may have something to do with the fact that the patch was
embedded in a web page and I've found that getting patches from web
pages often produces stray carriage returns which break parts of the
patch.  gcc DOES seem to work, but I'm a bit dubious on that fact...

I'm also slightly concerned because the fileutils problem (ls didn't
work properly) slipped right past me after initial compile time... It
exited with a 0 and installed the utils...this concerns me because it
leaves some doubt that everything compiled quite right on the Red Hat
7.0 system...Obviously, there are too many programs in the static build
to test out all of the functionality manually, so it's kind of difficult
to say what may or may not be broken.  Even if I took the time to test,
it would be difficult to determine what obscurr bugs were compile
related and what bugs originated in the package itself.

End Conclusion: Red Hat 7.0 is not a decent environment for building an
LFS implementation (or any software, for that matter)...

I am determined, though, to find a way to do this.

I believe that it can be done by building glibc 2.1.3 and staticly
linking all files to the 2.1.3 library on the LFS partition.

we can't simply replace the glibc on the Red Hat system because that
would break that system...

now, the ld info page claims that any library search directories added
from a -L flag will be searched FIRST...that is before the default
directories /lib and /usr/lib ...  I tried adding the
-L/lfs/mnt/working/lib -L/lfs/mnt/working/usr/lib to the LDFLAGS
variable in the Makefile and it didn't work...

the info page also says that you can add multiple -L flags...

I suppose the issue right now is whether there's a way to make ld
disregard it's default search directories and force it to use the
libraries from the LFS system...

in this case, it would be optimal to build the glibc first, then build
the other programs using the glibc...

just some thoughts...what do you guys think?

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

More information about the blfs-support mailing list