How to build XFree86 and keep your hair
bdubbs at swbell.net
Fri Oct 11 15:23:26 PDT 2002
dagmar at speakeasy.net wrote:
>OKay, on this issue I'm neither here nor there, but I *do* think the
>following paragraph is absolutely _hilarious_...
> "Because XFree86 is such a large package, you may find that hdparm-5.2
> speeds up compilation and running the package by tuning your hard disk
> for optimal performance."
>Now, apparently so far it's not been causing trouble for anyone (that
>we've heard from again muahahaha), but I've found that lately (and
>especially in the case of equipment of recent manufacture) hdparm is
>seldom even necessary anymore, but I've dealt with _many_ people who using
>hdparm turned things on that _they_ thought were perfectly reasonable,
>only to learn about massive filesystem corruption because of using the
>wrong type of IDE cable, and my personal favorite "It sounds like angry
>little gnomes are whacking the hell out of my hard drive when I turn that
>on!". What better way to test your new drive parameter settings than by
>spending four or five hours driving the system like mad and reading and
>writing a few hundred megs of data on your OS drive... Heheheh...
The operative word is *may*. hdparm is not for everyone and I've
received no complaints (except this one).
>OKay, now on to useful things, in order of decreasing importance...
> - The cryselephantine host.def cited in BLFS specifies "#define
> DefaultGcc2i386Opt -O2 -fomit-frame-pointer -march=i686" which without
> comment is incorrect. -mcpu=i686 might be appropriate, but telling the
> system to build only for an i686 (using -march) when the user might only
> have a simple Pentium MMX could have some less than optimal results.
> It should be changed to -mcpu or that comment area should explain to
> the user that they may need to change the variable to something more
> apropos for their CPU.
> - Trust me on this one, if XFree86 figures out you have an AMD CPU. it
> doesn't default Has3DNowSupport to NO.
The text says right in the host.def:
* If you read and configure only one
* section then it should be this one. The Intel architecture defaults are
* set for a i686 and higher.*
>- "#define LinuxDistribution LFS" doesn't actually do a damn thing that I am
>aware of. There's a short list of the ones it recognizes in one of the
> other cf files, and they all start with Linux<mumble>. (search for
> mumble). As far as I've been able to tell, it doesn't even get copied
> into a binary for branding reasons unless it matches one of the fixed
> ones. Useless option--should be yanked.
What it does is ensure that a default like "RedHat" is not set. In any
case, it doesn't hord anything.
>- Out of all the defaults that are being forcibly set, the only one I see
> of real merit is "#define SystemManDirectory /usr/share/man"
> - Setting "#define HasPam NO" is going to really piss off those people
> who went the extra mile and installed PAM into their login system.
The normal LFS default is without PAM. Users who make changes are on
their own (from the book's perspective).
> - Don't get too excited throwing things out... one line that catches my
> eye that's being set that actually _should_ be set is the one that sets
> "#define HasZlib YES" which keeps Xfree86 from building it's own buggy
> and old version of zlib. The build of cvs avoids this pitfall and so
> should X.
> - Okay, here's the tough one to sell because I've got nothing but years
> of experience backing me up on this point. On general principle,
> specifying _explicitly_ things which default to the exact same options
> is ba-a-a-a-ad juju. Currently the XFree86 section does a _lot_ of that.
I put them in because they were recommended to me. Now you are
recommending otherwise. Having the defaults may be useful to help
people know that they at least exist. Perhaps they should be commented
out however. I need others to tell me their opinions.
> Unless you like your system configuration to pitch and roll like the
> high seas between package updates, it's a _far_ better thing to specify
> only the defaults you _must_ have, and leave the rest alone. Keeping
> things simple ensures the _best_ chance that a package behaviour will
> not change significantly or in a detremental fashion between even minor
> revisions. If you specify explicitly all or most of the defaults, then
> you might get away with it... but eventually it'll backfire, and at
> best you'll wind up disabling a new and useful feature, or in the
> worst case, break something because your defaults didn't take into
> account possible future changes. Even documentation like BLFS should be
> maintainable over time--just because you've come up with a really flash
> way to do something in great detail this particular time doesn't mean
> it's going to _stay_ that useful forever.
> Furthermore, having such a massive list of things to put into the
> host.def is just _encouraging_ users to cut and paste the entire thing
> over, which is something I was under the impression had been decided
> was not a good behaviour to encourage because the users will do it
> without so much as spending a moment thinking about whether or not
> they need to change something, or worrying about the mild phrase "Error
> 1" means anything before proceeding through the next 10 packages
> compounding the problem. That entire file could be cut down to less
> than 10 lines and then it might actually still be useful with 4.3.0.
Unsubscribe: send email to listar at linuxfromscratch.org
and put 'unsubscribe blfs-dev' in the subject header of the message
More information about the blfs-dev