building X from source code on a Slack Box
 

Hello,

Has anyone built Xorg's X server from source on their Slack 12.1 box.

It there a HOWTO, or lessons learned, or forum somewhere to help
the process?

Why? you may ask. Be cause I "maybe" can!

--Chris

Hello Chris,

Slackware packages are built from source using scripts called Slackbuilds.

For the X server, here is a mirror of the official slackbuild with its source:

http://slackware.osuosl.org/slackwar.../source/x/x11/

To know more about slackbuilds, there are various resources on the web, but I would suggest:

www.slackbuilds.org

Regards,

Christophe

General howto about slackbuilds scripts can be found here

For a better overview of building X, you might do weel to checks out jong357's jaguar linux and also the slackx project. Both of these projects were building modular x for slackware before PatV was and I suspect that PatV may have based his builds on the work of one of them. The slackx project has probably not been upüdated to the latest release of X, but his material includes much better description files (slcak-desc) which you might want to use.

The hardest part is determining $VERSION numbers for each module. Last I checked, Slackware was doing rolling-current releases. Meaning, using development versions intended for the next stable release. I tried that for quite a few months at first but it's way too problematic so I started to build stable $VERSIONS only as defined by the Xorg Foundation.

http://xorg.freedesktop.org/releases/

I'm also not remotely interested in modular packages so I build monolithic 'package sets'. That leaves me with these packages for Xorg:

dejavu-fonts-ttf-2.23-noarch-1.tgz
fontconfig-2.5.0-i686-1.tgz
freetype2-2.3.5-i686-1.tgz
libdrm-2.3.0-i686-1.tgz
mesa-7.0.2-i686-1.tgz
ttf-bitstream-vera-1.10-noarch-1.tgz
xorg-app-7.3-i686-5.tgz
xorg-data-7.3-noarch-1.tgz
xorg-driver-7.3-i686-1.tgz
xorg-font-7.3-i686-1.tgz
xorg-lib-7.3-i686-3.tgz
xorg-proto-7.3-noarch-1.tgz
xorg-server-1.4-i686-3.tgz
xorg-util-7.3-i686-1.tgz

With each Xorg version, someone different is assigned to release, and up to this point, uploading the correct module versions is nothing more than an after thought. I was told, in a nut shell, by Alan C @ Xorg that they couldn't be bothered with having the correct version modules listed at the above link because they were too busy with the actuall development to care about such things. It's up to the packagers to find out what builds with what apparently.

It's like going to the abiword ftp site and finding abiword-2.6.4, abiword-plugins-2.6.2, abiword-docs-2.6.3 and abiword-extras-2.6.1 all in the same 2.6.4 release directory.

Anyway... My point being that's it's frustrating to build for that reason alone. Your going to need an automated way to grab all tarballs (and correct versions) otherwise you might as well forget about it. I wrote picklist for just this purpose so it may be of use to you. I know Vector uses it and possibly others.

Dan N @ Xorg told me that he would try to crack the whip with each release upload to get all this stuff sorted. He has a vested interest in things being correct as well since he's also a developer @ {B}LFS. (think wget files).

jong357, I'm glad you chipped in to this thread. I had noticed that Vector was building monolithic packages. Though I am interested in modularity, in the case of X I think they went too far and I deplore the mess of replacing what were 5-7 packages with 237 packages -it even caused a breakage in pkgtools which couldn't handle so many file names.
Seeing your nice short list makes me resolve to re-visit your build system for X.

Yea, technically their is nothing wrong with modular packages; I'm just stubborn and was too used to the imake way of doing things. That and I can't stand to have a cluttered package listing under pkgtool. So, after much trial and error, nothing much has changed over here... Still short and sweet.

If I want to just update, say for instance, pixman, then I can spare 20 minutes to rebuild all of xorg-lib... Going modular was only intended to make things easier on the xorg devs, not packagers.