Download your favorite Linux distribution at LQ ISO.
Go Back > Forums > Linux Forums > Linux - Distributions > Slackware
User Name
Slackware This Forum is for the discussion of Slackware Linux.


  Search this Thread
Old 10-07-2006, 01:56 PM   #1
Senior Member
Registered: May 2003
Location: Columbus, OH
Distribution: DIYSlackware
Posts: 1,914

Rep: Reputation: 52
Xorg-7.1.1 build scripts

Greetings all. I've had quite a few emails concerning some X11R7 .SlackBuilds that a made a little while back so I thought I would share them since some people are interested.

The main reason for upgrading would be compositing I suppose. That's the initial reason why I started writing them anyway. Gnome's Metacity-2.16.0 compositing feature seems to have gotten more stable as well and the Start Page is now advertising that option. Compositing is the way of the future I guess. Regardless of composting v7 is the latest release and we'll all end up running it sooner or later, so why not tackle it now?

A few notes first... I'm getting pretty burned out on the whole thing. I knew it would be quite an undertaking switching to the modular build system. The scripts are about 90% done. Maybe more. Just depends on how anal you are. They are completed to the point where everything builds and X runs just fine, however they REALLY need some tweaking. I would REALLY, REALLY apreciate people helping me out on this and posting diffs on this thread if you find ANY problem with ANYTHING. It would be nice to see these scripts evolve so everything is 'proper'. If you notice something wrong, please post a diff so other people don't have to solve the same problems...

ALL diffs by myself will be posted seperately, but in the same directory, as the X11R7 build scripts. They will be dated/numbered AND cumulative. Just grab the latest patch and apply from with the build script directory.

1. Location, location, location...
Is everything where it's supposed to be? I don't know.
Probably not. The app-defaults directory is a good example.
I've used $XORG_PREFIX and $XORG_CONFIG so you can easily
change those and I've tried to take into account people using
other prefixes, ( by creating compat symlinks where
appropriate if $XORG_PREFIX != /usr) but I highly suggest you
don't and use /usr for the prefix. Your on your own if you
start changing things. Back to the app-defaults directory. I
use $XORG_PREFIX/share/X11/app-defaults... There is an
inherent problem with building on a system that was already
set up for /usr/X11R6... I don't have this problem on my DIY
build. The letters "X11R6" have never even touched my system,
so I only have /usr/share/X11/app-defaults.

2. Mesa, mesa, mesa... What a crappy package. The way my scripts
work is that they will always fetch the latest source code of
whatever it's trying to build for, with the exception of
freetype and fontconfig. Mesa is going to have to join that
list. They have apparently taken a que from UDEV and decided
to start breaking things. There is a yes/no option in the
mesa script that you can change if you want to go the latest
version route. If you do that, you'll have to figure out any
xorg-server problems on your own. I've made headway but
gave up after awhile. The default is to use 6.5...

3. Preliminary work on compositing has been done but still needs
further work. Read the comments in the xorg-apps build script
for more info. Keep an eye out for diffs on my file server
for continued implementation but I can't say for sure when
I'll get around to it.

4. The 'evdev' module from xorg-drivers requires 2.6 kernel
headers. If 2.6 headers aren't found at script run-time,
evdev isn't even attempted. I'm running without it right now,
but that is a rather important X module to have...

5. Freetype. Do yourself a favor and ditch the slackware version
and use the included build script. I still haven't figured
out why Pat doesn't enable hinting. Everyone in the free
world does and they haven't gotten sued by Apple yet...

6. Fontconfig. Might as well build the newer version of this as
well, if for no other reason, than to have a newer version.

7. Fonts... This appears to be a problem in my scripts tho I
can't say for sure. The fonts on X11R7 are well... Crap. The
only thing that saves you on Slackware is the stock
dejavu-ttf package that comes with 11.0... dejavu is
supposed to come with xorg-fonts but they are not showing
up. Mainly, the only problem I'm having right now is with
fonts. I use Bitstream Vera on a global basis (now called
dejavu) so this is a problem. Leave the dejavu-ttf font
package installed and imediately switch system wide to them
or you'll probably get as irked as I am about it. This is
what I'd like help with the most. Figuring out if there is
indeed a font problem and how to remedy it. (hint, hint )

8. About always grabing the latest source code. I was adverse to
this in the beginning because that's never a good idea but
the maintainance burden of specifying hundreds of static
versions of modules just made me want to give up the whole
project before I even started so I knew I had to come up
with something automated. Just think about the next time you
wanted to build it again . You would have to spend hours
changing version numbers. IMO, they way I've set the scripts
up, is the ONLY feasable way to build this beast. Not only
grabing the latest packages, with the exception of freetype,
fontconfig and mesa, but filtering the hundreds of packages
thru a for loop. It works really nice and I forsee no
problems with this method except for rouges like mesa. I'm
banking on the idea that since they went modular, everyone
is going to be closely working with one another and making
sure all modules play nice with one another. If that's not
the case then going modular was a completely asinine idea...

9. I don't incorporate CFLAGS into my scripts. I believe that's
best handled from your shell environment. All the $ARCH
variables are set to i486 so if you really want them to be
i486 then make yourself a ~/.bash{rc,_profile} and
/etc/bashrc to export your CFLAGS...

10. The xorg.conf* files in ./extra are custom made for my boxes
and the "sample" config still leaves alot to be desired.
You'll have to come up with your own xorg.conf files, I'm
sure... Sorry. This is another area where I could use some
help; is coming up with a defacto xorg.conf-vesa or

11. I've left you little notes that are outputted to the console
after each script finishes regarding what script to run
next. Follow them carefully!!! I wrote the scripts and have
run them MANY times and I STILL screw up by not installing a
package afterwards if that's what it says to do. I think I
can atribute this to sitting at the init3 console and
getting spaced out by the black screen and white text. I
don't know... Suffice it to say, it's easy to
screw up on the build order. If you do mess up, then you
need to be aware of one thing. You may not be able to just
re-run the last script and pick up where you left off. This
is due to having a couple "first pass" scripts where you
don't actually install a package. We are satisfying deps by
having the first pass automatically build a temp package and
install it, then a script or two down the road, it will
uninstall the child package after the "final" parent is made
and ready to be installed "officially". If that sounds iffy,
it isn't and don't sweat it. Go read thru the scripts and
see what I've done before you shake your head. If I didn't
do this, then we would have quite a few more packages than
we do now. Example: luit should be built after xorg-fonts
but xorg-fonts requires a package from the xorg-apps
package. Luit IS a part of the xorg-apps package
but xorg-apps needs to be run after xorg-fonts
We wind up with a chicken and the egg problem. Since luit
is a part of xorg-apps I refuse to build it solo...
The script determines what pass we are on by the existence
of any temp packages in /var/log/packages... If you forget
to install a package and a second-pass package is next, the
second-pass package will removepkg on the temps and now your
left with having to backtrack to the original first-pass to
get those temp modules back on the system otherwise you'll
be building a first-pass instead of a second-pass.
As long as you pay attention to the notes at the end of each
build script run, you'll be golden. The best thing to do is,
use VC1 for ONLY executing the scripts. Use the other VC's
for side work, such as viewing the logs, so you never loose
sight of what it says to run next. Oh yea........
I redirect output to log files. The only thing you'll see
after runing a script is the fetching of source and then a
"Please wait while xyz builds..." Right above that, it
tells you the loaction of the log files if you want to
tail or cat them on another VC.... I DID NOT tell
the scripts to exit upon errors so it is up to you to
religiously check your logs after each script before
moving on to the next one. Just checking *.err will suffice.

Well, I think that's about all the thoughts I have. If that last excerpt confused you, then join the club because I still get confused over it at times.... I've tested these alot tho and everything works as it should AND for a reason. Give it a test run and you'll find out that it's actually very straight forward. All that confusing stuff is hidden and everything is auto-resolved. Just stick to the build order and it's painless. I'll post the build order here just so you can actually see it:
xorg-data (first pass)
xorg-apps (first pass)
xorg-data (final)
xorg-apps (final) (compiz needs gconf2)
xorg-docs (haven't made the script yet)
fontconfig (final) (this used to be the case anyway)
I'm sure I'm missing some "gotcha's". If I think about them, I'll ammend this post. As a general rule, you'll want to read ANY script before you run it, only the ignorant wouldn't do so. By reading them, you should see any potential things you might need to change. And, as stated, post your feedback/expierences/diffs.. It will be much apprecieated.

One last note about the file server directory from the top link.. All packages/scripts there are intended for use on a DIY/LFS build using a modified pkgtools. The main modification being the use of "desc" instead of "slack-desc"... Otherwise, they are ALL .SlackBuilds. I'm going to revert the X11R7 scripts back to using $ARCH=powerpc and slack-desc-->desc just so I can keep them all uniform. If you download the X11R7 scripts, do this from within the extracted folder:
sed -i 's@ARCH=powerpc@ARCH=i486@g' *.build
sed -i 's@install/desc@install/slack-desc@g' *.build
Now you have .SlackBuilds...

I really don't think I need to post a disclaimer, but here goes anyway... ANYTHING you download from the above link should be considered BETA and potentially harmfull to your system. It's possible that your hard drive might catch fire after running, though I would tend to blame that on the mesa devs and not my script... To the best of my knowledge, my scripts will not erase your /etc directory nor should they cause any damage of ANY kind, but that is not explicitly guaranteed. :-)

Last edited by jong357; 01-11-2007 at 10:47 AM.
Old 10-07-2006, 10:24 PM   #2
Senior Member
Registered: May 2003
Location: Columbus, OH
Distribution: DIYSlackware
Posts: 1,914

Original Poster
Rep: Reputation: 52

I've done some pleminary work with compiz from the xorg-app package and it basically wants packages that aren't even on Slackware... No suprise I guess.

In order to build compiz against KDE, it wants QT4..

In order to build against GTK, it want's libwnck, gconf2 and others.

To build against Gnome it obviously requires GTK and Metacity...

It can build against DBUS..

Basically the only thing it picks up on is librsvg and I think you have to specify that manually....

You guys are really going to have to install bleeding edge libs to get compositing to work... I'll keep working on it...
Old 01-01-2007, 08:19 PM   #3
LQ Newbie
Registered: Jul 2005
Distribution: slackware
Posts: 12

Rep: Reputation: 0
I've been messing around with your build scripts a little... had to adjust the mesa script:

mv showfiles.php\?group_id\=3 index.html
grep -o 'f=".*bz2' index.html > new

sed 's/<.*//' new2 > new3
grep sourceforge new2 |rev |cut -f 1 -d ">" |rev > new3

I also changed the prefix to /usr/X11R7 for everything but fontconfig and freetype, as it makes it easier to link X11R6 to X11R7 (I've completely removed all slack packages that reside in /usr/X11R6 for now). With this change, I also had to change how pkgconfig files are handled (I'm moving them into /usr/lib/pkgconfig, and I've linked /usr/lib/pkgconfig to /usr/X11R7/lib/pkgconfig). I also needed to change my /etc/profile and a few other files in etc that reference X11R6 - just changed to X11R7.

The resulting slack packages are working with kde and dropline gnome, but I haven't tried installing them on a clean system yet...
Old 01-01-2007, 08:53 PM   #4
Senior Member
Registered: May 2003
Location: Columbus, OH
Distribution: DIYSlackware
Posts: 1,914

Original Poster
Rep: Reputation: 52
Right on... They must have made some changes to their website then.. I haven't run those build scripts in about a month. I'll update them sometime this week. Might be better to just cat a PKGLST instead of wgeting/seding seeing as how a static version of mesa is defined. That function is a hold over from pulling the latest versions via ./picknew. I just left it in place not thinking it would cause a problem...

Just curious, your using the static versions that I have defined? or are you messing around with the 'picknew' aspect of it?

That was a REALLY bad idea on my part... Gave me nothing but headaches trying to keep up with all the developmental changes...

As soon as a stable 7.1.2 or 7.2 arrives, whichever comes first, I'll try to update them.
Old 01-01-2007, 10:09 PM   #5
Senior Member
Registered: May 2003
Location: Columbus, OH
Distribution: DIYSlackware
Posts: 1,914

Original Poster
Rep: Reputation: 52
By the way, that 4shared web site is being really wierd. Random files are getting removed for no apparent reason. The latest xorg scripts was one of them.

I've been meaning to get my own server up and running for quite some time now. Looks like a good opportunity to do so.

I'll systematically hunt down all my posts with that link and replace it with a new one once my server is up. If your interested in those scripts, just sit tight for a week or so. I'll find a new home for them.
Old 01-01-2007, 11:52 PM   #6
LQ Newbie
Registered: Jul 2005
Distribution: slackware
Posts: 12

Rep: Reputation: 0
haha, I was wondering why the scripts disappeared...

I left all your static-versioning sed commands in the scripts, so I suppose it is just keeping them static (even though it is still running picknew). That was going to be my next task, checking through to see what is still static, and what is pulling the newest version. Right now I'm still working on making it as similar to the default slack x11 packs as possible (keeping with the /usr/X11R* layout) - it seems to be working well.

I'm currently using some "pinki" builds of xorg which I got from sourceforge, in combination with some other beryl packages for a nice aiglx/beryl setup. However, it is a little buggy, so I'm planning on comparing your build scripts to the pinki ones (compare patches, configure options, etc.).

I haven't done much research on mesa yet - have you had any luck with 6.5.1? (or .2 if that's out?)
Old 01-02-2007, 12:20 AM   #7
Senior Member
Registered: May 2003
Location: Columbus, OH
Distribution: DIYSlackware
Posts: 1,914

Original Poster
Rep: Reputation: 52
EVERYTHING should be static with the last tarball I uploaded, which is now gone. The version numbers are defined in extras/$PKGNAME-static except for mesa, which I still run the picknew script but then just sed the VERSION back to 6.5 as you've noticed...

Hey, If you have the time or inclination, I wouldn't mind seeing a diff of the mods you've been doing. Up to you. Out of the hundred or more people who have downloaded those scripts your the only one who's bothered to comment on them. Pretty annoying...

I still have a TODO list for those scripts. I have a bunch of such projects going on. Think I bit off more than I can chew, time wise. Still need to add beryl and get composting integrated. Think I've abandoned the compiz route.

I'm pretty sure Fedora and others are still using Mesa-6.5.... The mesa devs are on some serious crack and better get their act together soon. It keeps getting more and more broken with each release. Actually, Fedora might be on the latest. The big problem is, that they are not keeping up with the development of xorg-server.

I knew as soon as I heard about the plan to go modular, that some people were going to slack off and not play ball. It's really frustrating for the builder. I really miss the imake system...

Also, since I went static, there are a number of security patches that should be applied to various progs. Get on the homepage of Xorg and see. That's another thing I was going to do with the next update. So little time...

Last edited by jong357; 01-02-2007 at 12:29 AM.
Old 01-02-2007, 10:31 AM   #8
LQ Newbie
Registered: Jul 2005
Distribution: slackware
Posts: 12

Rep: Reputation: 0
I just did a quick diff -u - here they are:

(that is my webserver).

Aside from adjusting the mesa build, I've changed all the XORG_PREFIX's to /usr/X11R7 (left freetype2 and fontconfig in /usr), and then I added in some pkgconfig cleanup (to move pkgconfig files from /usr/X11R7/lib/pkgconfig to /usr/lib/pkgconfig). It's still a little messy, but I'm going to be messing around with it this week...

I'm doing all the building in vmware, but my system is using packages from here right now:

Beryl is working, just a bit buggy, and since that pinki build script is not in english, I figured I'd start with your script and then compare. I definitely like how your scripts are separated, as it'll allow you to do more individual type updates (I think... so long as everything isn't dependent on what you're recompiling). The pinki build and official slackware builds are more or less (much more than less) single all-encompassing scripts.

I'd really love to get beryl up and running though, so once I have some proper packages, I'll get to testing that. That tiscali site does let you download their build scripts, so hopefully it won't be too painful.
Old 01-02-2007, 10:36 AM   #9
LQ Newbie
Registered: Jul 2005
Distribution: slackware
Posts: 12

Rep: Reputation: 0
oh, this is my first time trying to build xorg more or less from scratch (aside from a gentoo install I have... but I don't count that, as all I did was emerge xorg), so any random tips would be great! It seems that your scripts are pretty explanatory.

I was thinking that perhaps your picknew script could be separated into a pre-build-xorg script to help build a single list of packages, which you could edit prior to running all the scripts (and therefore allow you to statically set the versions, but dynamically download the most current list)...
Old 01-06-2007, 10:54 PM   #10
LQ Newbie
Registered: Jul 2005
Distribution: slackware
Posts: 12

Rep: Reputation: 0
alright, I think I got it!

i had to change your mesa build - i'm using mesa's glut and a few more configure/compile options. you were also missing a few options in your xorg.conf in the Screen section (i've included an updated xorg.conf in my source).

so, now i have xorg-7.1.1 and beryl-0.1.4 up and running on slackware11, and WITH dropshadows (finally)! here's a screenshot:

if you check out the xorg build scripts, make sure to take a peak at README2
Old 01-07-2007, 06:40 PM   #11
Registered: Dec 2005
Location: "The South Coast of Texas"
Distribution: Slackware64-current
Posts: 507
Blog Entries: 1

Rep: Reputation: Disabled
Advice, please

I have been lurking on this thread from its beginning. This is a subject that I have been interested in for a while. I have a fresh install of Slackware 11 in a qemu environment. I think this may not be appropriate as the video system presented by qemu may not work properly. I will probably make a new partition on my hdd & put another fresh install there. I'm planning on installing X7 into an install that doesn't have X in it all. Is this the best strategy? Have either of you come up with any other tips that might help me out? I'm rather looking forward to this experience, even if it doesn't work completely, it should teach me a lot.
Old 01-07-2007, 08:32 PM   #12
LQ Newbie
Registered: Jul 2005
Distribution: slackware
Posts: 12

Rep: Reputation: 0
although the video system in qemu might not let you run x (it should work with at least the standard "vesa" driver I would think), you should be able to build x without a problem. (I built x in vmware)

For my vmware image, I used a full install of slack, and then went into the /var/log/packages directory and ran a command to see what was living in /usr/X11R6:

cd /var/log/packages
grep X11R6 * |cut -f 1 -d ":" |uniq |sort

I then removed those packages, made a few system wide changes (changed the references to X11R6 in my path and files to X11R7), changed a few symlinks, logged out and back in, then started building.

There are some more detailed steps in the README2 file in my source files.

I think the best idea is to have a basic system image (like a vmware image) with your stock install, and make copies of it to work on, so that way you can start over easily and quickly.

hope this helps!
Old 01-07-2007, 09:03 PM   #13
Senior Member
Registered: May 2003
Location: Columbus, OH
Distribution: DIYSlackware
Posts: 1,914

Original Poster
Rep: Reputation: 52

I've noticed a few things in the limited ammount of time I spent looking thru your tarball. Everything in source/ is redundant. In fact, they might even nullify extras/$PKGNAME-static and/or specific $VERSION/$PKGVER variables (fontconfig/freetype). But for the most part, they should get overwritten via script functions.

You've disabled the kernel-headers check in drivers. Not a big deal but if someone else is running it and still has 2.4 headers installed, they'll get errors in xorg-drivers.err and wonder what is going on. An annoying time killer for the builder, nothing more. If 2.4 headers are found, an attempt to compile shouldn't even be made IMO...

For the secpatches, you should be using $srcdir and not $modname else if the src versions are higher than what the patch was intended for the patch process might stop waiting for user input but we redirect to logs. If it doesn't ask for input and skips the patch, then it should throw cruft in .err which is unnecessary.

Just little stuff at first glance. Not entirely sure about the copyright stuff either... GPL yes, ofcourse but you should probably check with the original author before you claim copyright on it, or presume to claim copyright on my behalf... I never was big on that sort of thing.

You've basically started a fork of my scripts. That's competely fine with me, but you should probably ditch my README and incorporate any relevant info from it with yours. Some additions you've done make some of my comments either null or confusing. Ditch stuff like that in the scripts. Clean em' up, make them yours and just throw a link to this thread in the README stating that you've forked from an existing set of scripts. Somethin'...

Actually, I think it would be more disireable for everyone if we just colaborated and came up with a new and improved tarball. I'm just really busy with work and various things so don't know if that's feasable or not. I was going to try and free up some time for another build and more modifications hopefully this coming weekend....
Old 01-07-2007, 09:25 PM   #14
Senior Member
Registered: May 2003
Location: Columbus, OH
Distribution: DIYSlackware
Posts: 1,914

Original Poster
Rep: Reputation: 52
I'm also curious as to why your optimizing for size on mesa. I've had mixed results doing that in the past and don't see a need for it anyway. Your defining the proto locations too. What's up with that? I'm assuming it bombed on you because it couldn't find the headers? Does it still do that if you don't comment out my sed filter?

Ughh.. I have to put this down till I get some free time. I should be sleeping right now...
Old 01-07-2007, 09:26 PM   #15
LQ Newbie
Registered: Jul 2005
Distribution: slackware
Posts: 12

Rep: Reputation: 0
hehe, i meant to ask you if you wanted that copyright info in there - it was late at night...

I'd prefer to try to keep the two "versions" as one, with user-definable prefixes (I know I missed a few spots in my scripts for that), as I don't think there would be all that much reason for separate scripts (actually, I'll probably be trying the scripts on x86-64 arch at some point). It wouldn't be hard to make all the slackware specific stuff optional. I'll try to take some time to clean up the scripts, and apply the suggestions you made, but I'm back to work this week... it will get done eventually though!

I'll post updates as I make them, and check back to see if you've updated anything.

...definitely right about the kernel headers check - I was running a 2.6 compiled kernel, but was trying to figure out problems at one point or another and commented that stuff out...


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off

Similar Threads
Thread Thread Starter Forum Replies Last Post
Build scripts say my C compiler cannot make executable output noware Linux - Software 2 06-07-2006 02:15 PM
New install, questions on xorg and shutdown scripts Randux Arch 0 03-01-2006 07:28 AM
samples of LFS build scripts dimaash Linux From Scratch 3 07-20-2005 09:35 PM
Xorg build error FlashAsh99 Linux - Software 4 06-29-2005 03:46 AM
Editting Build Scripts Corallis Linux - Newbie 1 06-30-2004 07:26 PM > Forums > Linux Forums > Linux - Distributions > Slackware

All times are GMT -5. The time now is 07:07 PM.

Main Menu
Write for LQ is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration