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
_______________________________________________
Xquartz-dev mailing list
Xquartz-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/xquartz-dev
