/bin/bash ../libtool --tag=CC --mode=compile i686-gentoo-freebsd6.2-gcc -DHAVE_CONFIG_H -I. -I../include -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 -D_THREAD_SAFE -DDBUS_API_SUBJECT_TO_CHANGE -I/usr/include/freetype2 -I/usr/include/pixman-1 -I/usr/include/hal -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include -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 -march=athlon-xp -O2 -pipe -MT utils.lo -MD -MP -MF .deps/utils.Tpo -c -o utils.lo utils.c i686-gentoo-freebsd6.2-gcc -DHAVE_CONFIG_H -I. -I../include -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 -D_THREAD_SAFE -DDBUS_API_SUBJECT_TO_CHANGE -I/usr/include/freetype2 -I/usr/include/pixman-1 -I/usr/include/hal -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include -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 -march=athlon-xp -O2 -pipe -MT utils.lo -MD -MP -MF .deps/utils.Tpo -c utils.c -fPIC -DPIC -o .libs/utils.o utils.c:1723: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'old_alarm' utils.c: In function 'Popen': utils.c:1747: error: 'old_alarm' undeclared (first use in this function) utils.c:1747: error: (Each undeclared identifier is reported only once utils.c:1747: error: for each function it appears in.) utils.c: In function 'Pclose': utils.c:1930: error: 'old_alarm' undeclared (first use in this function) *** Error code 1 man signal on linux: The use of sighandler_t is a GNU extension. Various versions of libc predefine this type; libc4 and libc5 define SignalHandler, glibc defines sig_t and, when _GNU_SOURCE is defined, also sighandler_t. here are git commit logs that should fix it: commit 6da39c67905500ab2db00a45cda4a9f756cdde96 Author: Eric Anholt <eric@anholt.net> Date: Wed Sep 12 13:23:13 2007 +0000 Fix build on FreeBSD after Popen changes. btw you'll probably want this one too : commit abe0a51f3f790f8c055289465e130177c4b647cc Author: Ben Byer <bbyer@bbyer.apple.com> Date: Fri Sep 21 17:07:36 2007 -0700 So, like, checking return codes of system calls (signal, etc) is good. Also, only restore an old signal handler if one was actually set (prevents the server from dying on OS X).
Created attachment 142430 [details, diff] Applies the upstream fixes suggested by aballier Here are the two upstream fixes suggested by aballier in a handy patch. I've confirmed the server compiles on Gentoo/FreeBSd with this patch applied, but have not tried to run it. Some handy gitweb links to the commits involved: http://gitweb.freedesktop.org/?p=xorg/xserver.git;a=blobdiff;h=144098b370c541c91405f78b725028096d0a1a87;hp=afcaae41ba475522dff4c765aae74e9b877b1628;hb=6da39c67905500ab2db00a45cda4a9f756cdde96;f=os/utils.c http://gitweb.freedesktop.org/?p=xorg/xserver.git;a=blobdiff;h=36c8dfeb38c1672a5650ff8f22ea2ba400c9f950;hp=144098b370c541c91405f78b725028096d0a1a87;hb=abe0a51f3f790f8c055289465e130177c4b647cc;f=os/utils.c
OK, the server runs on Gentoo/FreeBSD, at least.
Patch works for me too Gentoo/FreeBSD. Greatly appreciated Jose
as AT for g/fbsd i have tested the patch, it fix the compilation problem and xorg-server is running without any particular issue (i have tested it with gnome, kde-3, kde-4 and all works as excepcted). please add as soon as possible to the portage. thank you very much Jose!
Hi, in me side, the patch doesn't woork, in fact, i can't apply the patch : Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |--- os/utils.c 2008-02-01 13:10:39 -0800 |+++ os/utils.c 2008-02-01 13:20:59 -0800 -------------------------- Patching file os/utils.c using Plan A... Hunk #1 succeeded at 285. Hunk #2 succeeded at 1685. Hunk #3 succeeded at 1713. Hunk #4 failed at 1728. Hunk #5 failed at 1753. Hunk #6 failed at 1940. 3 out of 6 hunks failed--saving rejects to os/utils.c.rej Hmm... Ignoring the trailing garbage. done regards, JM.
(In reply to comment #5) > Hi, > in me side, the patch doesn't woork, in fact, i can't apply the patch : > > Hmm... Looks like a unified diff to me... > The text leading up to this was: > -------------------------- > |--- os/utils.c 2008-02-01 13:10:39 -0800 > |+++ os/utils.c 2008-02-01 13:20:59 -0800 > -------------------------- > Patching file os/utils.c using Plan A... > Hunk #1 succeeded at 285. > Hunk #2 succeeded at 1685. > Hunk #3 succeeded at 1713. > Hunk #4 failed at 1728. > Hunk #5 failed at 1753. > Hunk #6 failed at 1940. > 3 out of 6 hunks failed--saving rejects to os/utils.c.rej > Hmm... Ignoring the trailing garbage. > done > > > regards, > JM. > Only 1 out of 6 failed for me. And that's where I am stuck for now. The hunk number 5 failed for me, too.
(In reply to comment #6) > Only 1 out of 6 failed for me. And that's where I am stuck for now. The hunk > number 5 failed for me, too. Are you trying this on Gentoo/Linux?
(In reply to comment #7) > Are you trying this on Gentoo/Linux? No. Gentoo/FreeBSD-6.2 Anyways got it to work now. :) And things have gone fine.
(In reply to comment #8) > Anyways got it to work now. :) > And things have gone fine. > Care to share the fix with us?
The patch worked for me too on Gentoo/FreeBSD 6.2.
*** Bug 219721 has been marked as a duplicate of this bug. ***
any chance we can get this merged some day ? its a fix from upstream and the bug has been open for more than 4 months... and yes it still fails... and yes we're having dupes...
Yeah, I need to do a bunch of work on xorg-server and get a revbump with a ton of patches in it. I've been pretty busy lately, so I haven't gotten to it.
I've got a local copy of the upstream git 1.4 branch with these patches in it. I'll see if I can get them merged upstream.
Fixed in xorg-server-1.4.0.90-r4, which I expect to rekeyword as soon as a few last patches find their way in.