Xorg server 1.5.3 fails to build… because of glproto

So when I try to build xorg-server-1.5.3, I get:

/bin/sh ../libtool --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H -I. -I../include -I../hw/xfree86/os-support -I../hw/xfree86/os-support/bus -I../hw/xfree86/common -I../hw/xfree86/dri -I../hw/xfree86/dri2 -I../mi   -DHAVE_DIX_CONFIG_H -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wnested-externs -fno-strict-aliasing -D_BSD_SOURCE -DHAS_FCHOWN -DHAS_STICKY_DIR_BIT -I/usr/include/freetype2 -I/usr/X11R7/include -I/usr/X11R7/include/pixman-1     -I../include -I../include -I../Xext -I../composite -I../damageext -I../xfixes -I../Xi -I../mi -I../miext/shadow  -I../miext/damage -I../render -I../randr -I../fb -I/usr/X11R7/include -I/usr/X11R7/include -I/usr/include/drm -I/usr/X11R7/include/X11/dri -DXFree86Server -DGLX_USE_TLS -DPTHREADS  -g -O2 -MT glxdriswrast.lo -MD -MP -MF .deps/glxdriswrast.Tpo -c -o glxdriswrast.lo glxdriswrast.c
 gcc -DHAVE_CONFIG_H -I. -I../include -I../hw/xfree86/os-support -I../hw/xfree86/os-support/bus -I../hw/xfree86/common -I../hw/xfree86/dri -I../hw/xfree86/dri2 -I../mi -DHAVE_DIX_CONFIG_H -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wnested-externs -fno-strict-aliasing -D_BSD_SOURCE -DHAS_FCHOWN -DHAS_STICKY_DIR_BIT -I/usr/include/freetype2 -I/usr/X11R7/include -I/usr/X11R7/include/pixman-1 -I../include -I../include -I../Xext -I../composite -I../damageext -I../xfixes -I../Xi -I../mi -I../miext/shadow -I../miext/damage -I../render -I../randr -I../fb -I/usr/X11R7/include -I/usr/X11R7/include -I/usr/include/drm -I/usr/X11R7/include/X11/dri -DXFree86Server -DGLX_USE_TLS -DPTHREADS -g -O2 -MT glxdriswrast.lo -MD -MP -MF .deps/glxdriswrast.Tpo -c glxdriswrast.c  -fPIC -DPIC -o .libs/glxdriswrast.o
In file included from glxdriswrast.c:49:
glxdricommon.h:32: error: expected ':', ',', ';', '}' or '__attribute__' before '*' token
glxdricommon.h:36: warning: type defaults to 'int' in declaration of '__DRIcoreExtension'
glxdricommon.h:36: error: expected ';', ',' or ')' before '*' token
glxdricommon.h:38: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'systemTimeExtension'
glxdriswrast.c:67: error: expected ':', ',', ';', '}' or '__attribute__' before '*' token

(and a bunch more).

It took me a while to figure this one out. There are conflicting “GL/internal/dri_interface.h” files – one comes from Mesa and the other one from the glproto package (version 1.4.9) which is part of the Xorg distribution. Deleting the latter (at /usr/X11R7/include/GL/internal/dri_interface.h) made the problem go away.

It is a bit strange, though; why does glproto include that header file if it’s not needed – if it is, in fact, problematic?


Dbus 1.2.10 won’t compile

I get the following compiling dbus-1.2.10:

dbus-sysdeps-util-unix.c: In function '_dbus_init_system_log':
dbus-sysdeps-util-unix.c:457: warning: implicit declaration of function 'openlog'
dbus-sysdeps-util-unix.c:457: warning: nested extern declaration of 'openlog'
dbus-sysdeps-util-unix.c:457: error: 'LOG_PID' undeclared (first use in this function)
dbus-sysdeps-util-unix.c:457: error: (Each undeclared identifier is reported only once
dbus-sysdeps-util-unix.c:457: error: for each function it appears in.)
dbus-sysdeps-util-unix.c:457: error: 'LOG_DAEMON' undeclared (first use in this function)

(and so on).

The problem seems to be a missing “#include <syslog.h>” in the named file… if I add that in, it’s fine. How the how did this get missed? I mean, it DOESN”T COMPILE. How can you release a package which doesn’t compile?

I wonder if there’s something I’m missing, in particular, some situation (perhaps different ./configure options) which allow compilation without modifying the source.

Inconsistency in Rails

Good ol’ ActiveRecord::Base has a bunch of “update” methods with arbitrary semantics in regards to object validation:

update(id, attributes) – performs validation
update_all(update, conditions, options) – doesn’t validate, and reverses the operand order (what attributes to change first, followed by the records to change as specified by “conditions”, rather than the other way around). Note also that despite its name it doesn’t (necessarily) update all records.
update_counters(id, counters) – doesn’t validate, reverts operand order

instance methods:

update_attribute(name, value) – doesn’t validate
update_attributes(attributes) – does validate
update_attributes!(attributes) – does validate

A bit of consistency wouldn’t have gone astray. The instance methods are particularly bad – by what rationale does update_attribute not validate while update_attributes does??

ATI driver woes

There are no less than 3 choices for a driver when you have an ATI graphics card, it seems. This would be a good thing if any of them actually worked.

I have an X1250 (which is integrated into a 690G-chipset motherboard). The “radeonhd” driver works but doesn’t support TV-out, XVideo acceleration or 3D acceleration and so is really little better than the vesa driver at this stage. The “radeon” (or just “ati”) driver gives me a blank screen (I filed a bug report). The proprietary Catalyst driver (or “fglrx”) works except it is a pain to install (on my homebrew system), all OpenGL programs crash (looks like the opengl library provided with the driver is causing some sort of memory corruption or double-free?), and Xvideo output from MythTV results in a double-image (one on top of the other, as if there’s some sort of de-interlacing issue). Of course XVideo didn’t work at all until I set some option “TexturedVideo” in my xorg.conf file – the only hint I got to do that was the X sever logs; the option wasn’t documented anywhere. In fact, none of the options for the fglrx driver are documented officially.

I’ll also throw in a complaint at this stage about the “/etc/ati/amdpcsdb” file, and the fact that settings it contains silently override equivalent settigns in xorg.conf, so that you end up wondering why changing the xorg.conf file doesn’t appear to have any effect.

Back to the original story. Basically, three drivers just means I’m screwed three ways. I’m trying to build a Home Theatre PC and my only option for watching TV, at this point, is now to install the MythTV frontend on another machine (with integrated Intel video) and watch it on that.

Edit 14/04/2008: I got the double-image problem sorted – it was actually MythTV itself that was causing the issue, the standard de-interlacing filter converts the image into a double-height image with the fields one above the other and this is what I was seeing. It’s meant to then double the frame rate and show the two halves one at a time but for some reason that wasn’t happening. I’m partly to blame here because I’m using a subversion pull of MythTV rather than a released version.

Also, I’m pleased to report there’s been some progress with the open-source ATI drivers. The radeonhd driver made another release (1.2.0) which apparently does nifty stuff like 2D acceleration (still no TV-out, 3D, or Xvideo). Also, by using the latest drm module (latest pre-patch kernel release, 2.6.25-rc9) and switching to the EXA acceleration method I was able to get XVideo working with the radeon driver, which is pretty good, though it still can’t do TV-out, still blanks the screen if anything is connected to the composite output when I start X, and it now also leaves me with a blank screen when I exit X or switch to another VT. Never-the-less it’s great to see some progress on these drivers.

Can somebody hit the Mesa maintainers with the clue-stick, please?

I’ve been waiting a while for the release of Mesa 7.0.2 as 7.0.1 doesn’t include support for the G33 chipset in my motherboard, and as a result I’ve been running with a git snapshot, something which always makes me a little uneasy. It’s finally been released, but alas when I build (at “make install” specifically) I get an error:

make[2]: Entering directory `/usr/src/Mesa-7.0.2/src/glw’
make[2]: *** No rule to make target `glw.pc.in’, needed by `glw.pc’. Stop.
make[2]: Leaving directory `/usr/src/Mesa-7.0.2/src/glw’
make[1]: *** [install] Error 1
make[1]: Leaving directory `/usr/src/Mesa-7.0.2/src’
make: *** [install] Error 1

The problem is quite basic; The “glw.pc.in” file is MIA because it hasn’t been included in the source tarball. This is in itself fairly annoying but I take issue for two reaons: firstly, this error should have happened during the initial “make” and not “make install”. Secondly, obviously nobody tested whether Mesa could be built and installed from the tarball before it was officially released. This latter is really stupid.

On the plus side, with the 7.0.2 release Mesa finally has support for “make DESTDIR=… install”.

Edit 19/11/07: This is what “glw.pc.in” is supposed to look like. There doesn’t seem to be a directly downloadable version.

Edit 12/01/08: Entry in the bug database. Fixed for 7.0.3 apparently (not yet released).

Edit 06/04/08: Mesa 7.0.3 has finally been released (after 5 months), and yes, it fixes this problem. It should not have taken 5 months to fix this problem. Not being able to “make install” is serious.

Eclipse cannot “retrieve ‘feature.xml'”, apparently.

I was getting the following error message in Eclipse, when I tried to use the software update (which, for some inexplicable reason, is accessible from the “help” menu):

Error retrieving “feature.xml”. [error in opening zip file]

Other than the fact that it probably shouldn’t have been appearing anyway, what’s particularly galling about this error message is that it offers no clue as to what the f*ck has gone wrong, nor even why it matters. The only visible effect of this error was that the eclipse update websites didn’t appear in the list, and that a dialog with the error message would pop up with just about any action I would take (other than closing the update dialog completely).

Very, very, stupid.

I did what I have increasingly found to be the quickest and easiest method of solving problems such as these: A Google search. It led me to this web page:


…Sure enough, deleting site.xml from inside my eclipse installation directory made the problem magically go away. It turns out that the eclipse CDT (C development tools) zip file which I had downloaded, was actually meant for retrieval via the eclipse updater and not meant to be installed by simply unzipping it inside my eclipse directory as I had done. Clearly the CDT guys are partly to blame for this because they don’t seem to actually provide any other downloadable version.

But… I mean, should the presence of some file in the installation directory really cause such an annoying problem? And if it does, shouldn’t the error message at least attempt to explain what the problem actually is?