How to build XFree86 and keep your hair
dagmar at speakeasy.net
dagmar at speakeasy.net
Thu Oct 10 13:23:38 PDT 2002
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...
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.
- "#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.
- 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.
- 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
- 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.
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