FORK (was Re: Hold the phone! - last minute breakthrough!)

Michaël Tousignant evanidus at videotron.ca
Tue Sep 16 19:55:10 PDT 2003


Greg Schafer <gschafer at zip.com.au> wrote:

> Wow! You've got some front, advertising a fork of the book on lfs-dev? Why
> are you not working with the LFS team on this? Fork's are incredibly
> counter-productive. And you're even using the resources of the LFS irc

Well, I actually mentioned it thinking it could help. This fork exists for
over a month now, could've mentioned it a while ago. It's not
counter-productive if ideas are shared, I'm not trying to bring down LFS or
anything.

It's just that when you mentioned that keeping binutils-build was wrong, I
thought I'd show my implementation in case it could help improve LFS.

> I take one small look and the first thing I see is use of "-rpath-link".

Well, it's not -rpath, as you probably know -rpath-link is only for finding
libraries searched "by" libraries at linking time.

It's not needed during ch5, you can do it without. But w/o it, at compile time
the libc, due to some problems, will look for symbols (will not link with,
just use symbols) on the host's ld-linux.so.2. I thought this was way
wrong (or unclean) and could occasionate unpredictable problems on certain
hosts.

Also, this saves us some more hacks when in ch6. I personally find it better
this way (And never had any problems with that procedure either).

> Straight away I'm turned off :-(  You've also got some incredibly icky's
> sed's in there. I will get around to looking at your work eventually but on
> the surface it looks incredibly "un-newbie friendly" and I don't have enough
> time right now.

Well, I wanted to make the sed itself as portable as possible for the
different hosts this could be used on. For people who have problems with the
sed (like need to type it) there's a easy paragraph below for people using
common hosts/machines.

It could be simplifed by giving it more lines though.. I tried to have it do
more on each lines. I might consider simplifying by making it bigger.

For example:

's: /lib\(\|64\)/ld\(\|-linux\)\(.so.[12]\): /beaver/lib\1/ld\2\3:g'

handles /lib/ld-linux.so.2 /lib64/ld-linux.so.2 /lib/ld.so.1 and
/lib64/ld.so.1 replacements.

---

I just think it's still better than constently changing the ldscripts by
keeping binutils-build or even modifying /tools during ch6. At least in my
opinion.

Anyway, let's not turn this into a flame war, because now that'd be
being counter-productive. ;)

If you have any more comments or questions, please direct them to me rather
than lfs-dev unless you believe they concern LFS directly.

-Michaël Tousignant <evanidus at videotron.ca>



More information about the lfs-dev mailing list