[Xquartz-dev] Newbie question about building XQuartz: autoreconf fails

[Tom Lane]

I wrote:
> Any advice would be appreciated ...

... a few hours later, I have what seems to be a working Xquartz build.
Thought I'd document what I found out.  Some of this might just help
the next newbie, but some of it says Xquartz needs some work.

* The Developer-Info.html recipe implies you can just use the default
branch in the git repo, ie "master".  That one doesn't build, even though
Jeremy is evidently maintaining it in parallel with the active branch,
which seems to be server-1.18-branch.  So, check out the latter before
building.

* That recipe also suggests using --enable-maintainer-mode as a configure
argument, but configure doesn't recognize it.  Don't know if this is a
leftover or if there's some significant version skew here.

* I recommend adding -Wno-deprecated-declarations to the CFLAGS,
else you'll get so many of those you can't see the actual warnings.
(Of which there are not many, I'm glad to see.)

* You need autoconf, automake, and libtools in addition to the tools
mentioned on Developer-Info.html.  Best to let them install into
/usr/local as per default, else you'll need to adjust ACLOCAL.

* With a modern automake (I'm using 1.15.1), the autoreconf process
produces a boatload of warnings:

hw/dmx/Makefile.am:25: warning: source file '$(top_srcdir)/mi/miinitext.c' is in a subdirectory,
hw/dmx/Makefile.am:25: but option 'subdir-objects' is disabled
automake: warning: possible forward-incompatibility.
automake: At least a source file is in a subdirectory, but the 'subdir-objects'
automake: automake option hasn't been enabled.  For now, the corresponding output
automake: object file(s) will be placed in the top-level directory.  However,
automake: this behaviour will change in future Automake versions: they will
automake: unconditionally cause object files to be placed in the same subdirectory
automake: of the corresponding sources.
automake: You are advised to start using 'subdir-objects' option throughout your
automake: project, to avoid future incompatibilities.

Might be a good idea to fix that sometime soon.

* Building with current Xcode produces an X server that crashes at startup,
with a trace like this:

Thread 5 Crashed:
0   libsystem_kernel.dylib        	0x00007fff99cb5d42 __pthread_kill + 10
1   libsystem_pthread.dylib       	0x00007fff99da3457 pthread_kill + 90
2   libsystem_c.dylib             	0x00007fff99c1b420 abort + 129
3   libsystem_c.dylib             	0x00007fff99c1b592 abort_report_np + 181
4   libsystem_c.dylib             	0x00007fff99c41f28 __chk_fail + 48
5   libsystem_c.dylib             	0x00007fff99c41ef8 __chk_fail_overflow + 16
6   libsystem_c.dylib             	0x00007fff99c41fe3 __strlcpy_chk + 85
7   X11.bin                       	0x00000001007aa74b _XSERVTransSocketReopen + 555 (Xtranssock.c:537)
8   X11.bin                       	0x00000001007a68d0 _XSERVTransSocketReopenCOTSServer + 128 (Xtranssock.c:777)
9   X11.bin                       	0x00000001007a84b5 _XSERVTransReopen + 341 (Xtrans.c:532)
10  X11.bin                       	0x00000001007a834e _XSERVTransReopenCOTSServer + 78 (Xtrans.c:623)
11  X11.bin                       	0x000000010079e045 ListenOnOpenFD + 405 (connection.c:1307)
12  X11.bin                       	0x00000001005c28af DarwinEventHandler + 767 (darwinEvents.c:293)
13  X11.bin                       	0x0000000100777198 mieqP<rocessDeviceEvent + 472 (mieq.c:559)
14  X11.bin                       	0x0000000100777579 mieqProcessInputEvents + 665 (mieq.c:643)
15  X11.bin                       	0x00000001005c2b24 ProcessInputEvents + 20 (darwinEvents.c:422)
16  X11.bin                       	0x000000010071022b Dispatch + 155 (dispatch.c:356)
17  X11.bin                       	0x000000010071b958 dix_main + 1512 (main.c:300)
18  X11.bin                       	0x00000001005c6c70 server_thread + 64 (quartzStartup.c:66)
19  libsystem_pthread.dylib       	0x00007fff99da093b _pthread_body + 180
20  libsystem_pthread.dylib       	0x00007fff99da0887 _pthread_start + 286
21  libsystem_pthread.dylib       	0x00007fff99da008d thread_start + 13

I dug into it and determined that even though _XSERVTransSocketReopen is
being very careful to allocate the correct amount of memory, gcc is
deciding to generate a __strlcpy_chk() call that abort()s if the string
length is >= 14 bytes, because it thinks the declared size of struct
sockaddr.sa_data is a hard limit that it ought to enforce.

I worked around that by the expedient of adding -D_FORTIFY_SOURCE=0 to
CFLAGS, and that gave me an X server that seems to be working so far.
But that's a pretty crummy substitute for a proper fix.  I wonder why
other people are not seeing this.  I also wonder how the released
version of XQuartz is actually being built.

			regards, tom lane