How to build XFree86 and keep your hair

dagmar at dagmar at
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
  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.

  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
and put 'unsubscribe blfs-dev' in the subject header of the message

More information about the blfs-dev mailing list