DSL Tips and Tricks :: A quick guide on compiling XOrg 7.0 on DSL

A quick (and dirty) guide.
This was mostly done from http://wiki.x.org/wiki/ModularDevelopersGuide
(And from the XOrg mailing-list archive)

This has been tested with XOrg 7.
XOrg-git (to be 7.3 I gather, tested as of mid-Nov. '06) may be added later.

The order of installing the following stuff should be fine... please notify if they aren't.

What I used:

Fresh DSL livecd boot, nothing extra.  Tested with 1.5 and 3.01 as user dsl.
Plenty of free ram.  And cpu cycles.
And free disk space - about 3gb should be sufficient (depending on how much you install, and where you get your downloads).


Note: I suppose you could use gcc-2.95 to conform with the kernel


Note: Since perl 5.8.0 is included in DSL, but is a stripped version, I created this package to house some required files.

Taken from a 5.8.x perl package, you'll need
(this was for git, I can't remember if there were less just for 7.0)

For the following:
- download them
- unpack them via tar (or whatever format you got them in)
- configure them via ./configure
 <!> I used `./configure --prefix=/usr` to overwrite possible existing installations.
 <-> If you don't, there's likely going to be a conflict, or something can't find something else - but you can get around this by specifying the lib dir by `export LD_LIBRARY_PATH=my_library_path` and point pkg-config to where it's .pc files are located by `export PKG_CONFIG_PATH=my_pc_path`.
- make && sudo make install
(scripting and loops can really help here!)

extra packages (from Xorg):
- mostly from gnu.org; downloads can be accessed by http/ftp at ftp.gnu.org
- else sourceforge, google, etc. - you'll find their official homepages right away. or see the first wiki link posted above.

freetype-2.1.9 (this one required 2 'make install's for some reason to have a 0 return value)

some things (wiki says app/twm) require:
- Note: if you don't want to install these, you can comment/delete them out from the build script later on

if building mesa:

Mesa-6.4.1 (I only used libmesa)
<!> for this you'll need to do `make linux-x86 && sudo make install`
<-> installed this to system-wide /usr/lib/... as well
<-> If you decide to use gcc-2.95 you'll have to remove the -std=c99 flags, since 2.95 only supports c89 (from the linux configs)

- Unfortunately, gcc1 pacakge seems to come with pkg-config, so you'll just have to overwrite it.
- If you wish to use newer versions of certain packages with 7.0, you'll have to browse around for workarounds.  Although I did try newer ones, there's just too many workarounds required! (so they won't be listed here, see the xorg mailing-list archive for more details if you want to go this way)


"Wait! We haven't even gotten X yet!"
Oh right... well I decided to go with tarballs - bzip'd.
I got mine from the official repository: http://xorg.freedesktop.org/releases/X11R7.0/src/
You can either get the 'everything' dir... or everything else :P

Now, you get get the newest build-from-tarballs.sh script here: http://gitweb.freedesktop.org/?p=xorg....alls.sh and saved it to where_are_my_tarballs.

Now before you continue, you may have to remove some broken xrender stuff that something installed, unless you're using LD_LIBRARY_PATH and PKG_CONFIG_PATH.  So (re)move /usr/lib/pkgconfig/xrender.pc and /usr/lib/libXrender.*  If it's not there, then continue.

You may want to apply some security patches that have been made for 7.0 - I didn't know about them then.

And then I did:
cd where_are_my_tarballs
chmod +x ./build-from-tarballs.sh
PATH=install_path/bin:$PATH sudo ./build-from-tarballs.sh -m mesa_tar_extracted_dirname/Mesa-6.4.1 install_path &> build.log

Go build!

Optionally you can use `tail -f build.log` to view its current process (note that this may take up several more cpu cycles).

- I suppose I should've tried the "-s sudo" options or something (because of a problem later described)
- If you didn't want Mesa, you don't need to include the -m part
- If you didn't use bzips, you'll want to specify -gz
- If you got the everything dir, use -e
- For a general usage, just run ./build-from-tarballs.sh :)
- If you don't want certain parts, edit ./build-from-tarballs.sh, and prepend # to comment out lines (ie docs - since DSL by default won't use em manpages)


Running X.

cd ~/
Edit .xserverrc to point to your new Xorg binary.  You might want to add stuff to ie PATH=install_path/bin:$PATH and LD_LIBRARY_PATH=install_path/lib here.
For some reason, I can only `startx` with super-user priveleges, ie `sudo startx`.  Haven't been able to find a fix/workaround yet or what exactly is going wrong.

You'll probably end up seeing it try to auto-generate a xorg.conf here since you probably won't have one yet.
Well, it didn't work for me since it said that the system was using a framebuffer console and you'd need to specify the busid's of the video cards.  So I just downloaded one.  Or you could try running xorgconfig, etc.

You could save the xorg.conf to the general /etc/X11 or install_path/etc/X11 (if you decide on making a self-contained package), among other places.

Now it should load up, tada! yay! (hopefully). Enjoy the fonts!

The common error I get without running as root is on xf86ReadBIOS: Failed to read /dev/mem (Operation not permitted) in the X log, and it fails on Fatal server error: xf86EnableIOPorts: failed to set IOPL for I/O (Operation not permitted)

I have only been satified by starting xdm as a service to avoid the sudo startx.
After loading dsl-dpkg; apt-get update; apt-get install xdm,
/etc/init.d/xdm was edited to point to my new installation.
Created ~/.xsession - this is run by xdm for login stuff.
I placed
cd ~
and the usual PATH and LD_LIBRARY_PATH (as described above) in there
and appended the current .xinitrc contents (ie `cat .xinitrc >> /xsession`)

Note: if you use xdm you need at least one user's password set!
You can either boot with "dsl secure" or use sudo passwd (for root) and sudo passwd dsl (for user dsl)

Now start it up as root, like using `su -c "/etc/init.d/xdm start" -`
(Of course this isn't very secure since anyone can still kill this via ctrlaltbksp, etc. so you may want to disable that or use something like xlock, etc.)

And now you should have a pretty login screen (like what SU had in his older post in this forum).  I suppose for permanence this could be added to some startup/init script.

I know this is kind of a rushed guide, but it may serve its purpose.  I guess it wasn't as quick as I thought...
I know there is a problem with this, but I still think it's good as a guide for those who want to try it out.

Any feedback/comments are welcome!

Thanks to the XOrg team for their great work!

Looks like there isn't much interest in this, but I'll post this part anyways just in case someone wants the latest (and greatest?) and for future reference.  These notes are based on the previous (above).  Also some news: some of you may know that 7.2 final will probably be available sometime soon.

xorg-git as of mid Nov, 06
Heavily based on the guide from http://wiki.x.org/wiki/ModularDevelopersGuide (*)

Replaced packages:
( previous version installations were uninstalled with `sudo make uninstall`)

Additional packages:
libxml2-2.6.26 ( ftp://xmlsoft.org/libxslt/ )
libxslt-1.1.16 ( 1.1.18 causes gcc problems )

Bleeding-edge dev code:

** all the above is now built and installed in system **

Note: Looks like these also got moved to git repositories, so you should now use
drm-git ( http://www.mesa3d.org/repository.html )
Mesa-git ( http://www.mesa3d.org/repository.html )

I install git on another machine, then transferred the files, so I am unaware of the requirements to install git on a default session of DSL. (git: http://www.kernel.org/pub/software/scm/git/ )

xorg-git (*)
xcb-git ( xcb is the new and shiny replacement for xlib )

This time we will be using the build.sh script instead of build-from-tarballs because ... we aren't using tarballs now :)

Then I adapted the build lines to:
PATH=/tmp/modular/bin:$PATH ./util/modular/build.sh -m /tmp/Mesa-git /tmp/modular &> build.log

<!> Note: At this time, I had to pass --disable-dmx and --disable-xprint as well (because they were broken). Also, a new input system was in place, and only the default mouse, keyboard, and evdev input modules could be built.  You may want to pass -n to continue even if there are errors during build.  (Or comment them out in build.sh).

Hopefully now it will build, and now you have the binaries for the latest xorg to play with :)


This section applies to the both posts in general:

If you don't want to build certain things (like docs *cough*) you can easily delete them in build script, or delete them in the final output dir (docs, man, etc. folders).  There's probably some apps you will probably won't use either.

Also, if you don't plan on using the dev files, you can cut out
[file extension] (optional directory to seach for/delete)
.h (include)
.pc (pkgconfig)
.m4 (aclocal)
(and then take out empty dirs)

For example, you can use something like grep -e "\\.h$", and for directories you can use "\/include\/"

Other things to take out:
locale files (ie keep the ones you only use)
fonts (these take up quite a bit, but now theres many... a lot... to choose from. You get the idea.)

Enjoy :)

VERY impressive effort, I like heroic compiles on dsl :=)

Any chance you might be able to build a massive extension out of this (unc perhaps)?

I think we people with Intel915GM integrated graphics in our laptops need  XOrg6.9+ to stand a chance of getting graphics acceleration.

Well, I haven't gotten around to getting a better fix/workaround for the main problem (startx only by root), so that was what was stopping me from easily making an extension.  Maybe it needs some debian/knoppix patches?  I did plan on making an .uci with some of my install/configure scripts though.
This project is beyond anything I've tried so far. The last time I tried to compile an X system was a zipslack box, and that was before i knew how to use it =o)

Anyway, my point in posting this was to say that I remember reading that some systems require X to be built with setuid root. That was xfree86, but i guess it might still apply here.

This is just me guessing, though, as usual. Thought it might apply.

Next Page...
original here.