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?

Advertisements

Comcast is screwing its customers…

Comcast is screwing its customers by blocking “spam” which isn’t spam and also preventing mail servers which are accused of “spamming” from being removed from Comcast’s blacklist. I’ve tried to respond to two support requests from Comcast subscribers recently and in both cases, my reply bounced.

I got this back rom my mail server:

Reporting-MTA: dns; *********

Final-Recipient: rfc822;********@comcast.net
Action: failed
Status: 5.0.0 (permanent failure)
Diagnostic-Code: smtp; 5.4.7 - Delivery expired (message too old) 554-'IMTA06.emeryville.ca.mail.comcast.net comcast ***.***.***.*** Comcast BL004 Blocked for spam.  Please see http://help.comcast.net/content/faq/BL004' (delivery attempts: 0)

(Of course “***” are places where I’ve removed identifying information).

On following the link to http://help.comcast.net/content/faq/BL004, I get a page which suggests I can go to http://www.comcastsupport.com/rbl to get my mailserver unblocked. However, following that link redirects me to http://www.comcastsupport.com/browserupgrade/ which gives me a 404 Not Found.

Way to go, Comcast.

Update 25/8/2010: Seems like this has been fixed.

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.

Where is the Rails bug tracker?

The Ruby-on-Rails website has a link (“Get involved”) with a speech bubble picture, in which the words “bug tracker” (among other things) are contained. However, the link takes you to another page which links to a whole bunch of stuff, none of which is a bug tracker.

Hmm, there seems to be a tracker here:

http://rails.lighthouseapp.com/projects/8994-ruby-on-rails/overview

… but that doesn’t seem to have bug #3231 which was mentioned here:

http://www.ruby-forum.com/topic/39270

… and which I recently stumbled on.

It’s all very chaotic and unsatisfying. Much like Ruby programming…

fork/exec is forked up

I don’t know why it’s taken me so long to realise this, but the whole fork/exec shebang is screwed. There doesn’t seem to be any simple standards-conformant way (or even a generally portable way) to execute another process in parallel and be certain that the exec() call was successful. The problem is, once you’ve fork()d and then successfully exec()d you can’t communicate with the parent process to inform that the exec() was successful. If the exec() fails then you can communicate with the parent (via a signal for instance) but you can’t inform of success – the only way the parent can be sure of exec() success is to wait() for the child process to finish (and check that there is no failure indication) and that of course is not a parallel execution.

If you have a working vfork() then you can communicate with the parent process using a shared memory location (any variable declared “volatile” should do the trick, bearing in mind that “volatile” is not particularly well defined) although doing so is not standards conformant (see http://opengroup.org/onlinepubs/007908775/xsh/vfork.html for instance). By “working” vfork() I mean a vfork() which 1. causes the address space to be shared between the child and parent process (rather than copying the address space as fork() does) and 2. causes execution of the parent process to be suspended until the child either successfully exec()s or _exit()s. The 2nd requirement is necessary to avoid the race condition whereby the parent process checks the status variable before the child process has actually tried to exec() or similar.

Even the vfork() solution, if it can be used, is reliant on the compiler doing the right thing both in terms of volatile access, and in terms of vfork() generally. (Note that “right thing” in terms of volatile access is the generally accepted definition, not that in the C standard. Also, the fact that vfork()s correct operation really requires compiler support is something that I’m not willing to go into right now, other than to say that the compiler is allowed to make the assumption that “if (vfork()) { } else { }” will always follow one branch and not the other which is not the case here as both branches will be executed with the same address space).

The only other solution I can think of is to use pipe() to create a pipe, set the output end to be close-on-exec, then fork() (or vfork()), exec(), and write something (perhaps errno) to the pipe if the exec() fails (before calling _exit()). The parent process can read from the pipe and will get an immediate end-of-input if the exec() succeeds, or some data if the exec() failed. This seems like it should be fairly portable, as long as FD_CLOEXEC is available, but I haven’t actually tried it out yet.

---

Update 8/1/2009: The latter solution really requires fork() instead of vfork(), because vfork() might suspend the parent and the write by the child might then block, causing a deadlock. (In practice a pipe is always going to have enough of a buffer for this not to happen). POSIX doesn’t even let a vfork()d child call write(), anyway.

13/11/2015 also worth mentioning is the possibility for priority inversion to occur if the child process is to be run at lower priority and a third process is running at some priority level between the other two. The parent, which is running at the highest priority, should receive notification of fork-exec status as soon as possible; however, the child (running at the lowest priority) will not send this notification while the third process is scheduled.

This can avoided only by not waiting for exec to succeed or fail, but instead to process the exec status (data coming over the pipe or pipe closure) asynchronously (17/11/2015 or by eg using ptrace() to stop the child after exec() so that its priority can be set at that point; this wouldn’t work however if the child was setuid [unless the parent was root] since you can’t change the priority of a process not owned by yourself).

---

Update 18/9/2012: There’s a reasonably portable solution to this whole mess in the form of posix_spawn. (Update again 11/11/2015 – no. posix_spawn allows various errors to result in the child process exiting with a status of 127, so implementations may exhibit the exact same issue as the fork/exec combination. I somehow missed this earlier).

---

TL;DR – it’s not easy to determine immediately and without blocking whether a fork/exec pair of calls succeeded. If the child process is to run at the same or higher priority as the parent, you can do it with a CLOEXEC pipe trick; if the child process is to run at lower priority, the pipe trick suffers from potential priority inversion problems.

Multiple pkg-config incarnations?

Why the heck does ftp.gnome.org host (apparently two strains of) pkg-config?

http://ftp.gnome.org/pub/GNOME/sources/pkg-config/ (version 0.18 and 0.19)

http://ftp.gnome.org/pub/GNOME/sources/pkgconfig/ (version 0.8 through 0.18, though skipping 0.10)

It’s irresponsible to host out-of-date versions like that, as if pkg-config was part of the Gnome project and didn’t exist independently. At least put a README or something which mentions that this is a possibly-out-of-date mirror!

The real pkg-config distribution is here:

http://pkg-config.freedesktop.org/wiki/

with releases (including the current 0.23) here:

http://pkgconfig.freedesktop.org/releases/

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??