The automatic detection of launchd uses AC_CHECK_PROG with the user's PATH to check for the presence of launchd. If the user doesn't have /sbin in PATH, libxcb will be built without launchd support which cripples the library on OS X. Reproducible: Always Steps to Reproduce: 1. emerge libxcb 2. xeyes 3. Actual Results: Error: Can't open display: /tmp/launch-XXXXX/org.x:0 Expected Results: No error. x11-libs/libX11 uses the same method of detecting launchd, and thus has the same problem. Maybe other packages are affected, too?
Created attachment 237177 [details, diff] Make configure check in /sbin for launchd. This is where it's at, at least in OS X 10.5 and 10.6.
it is so on 10.4 too.
I went with --with-launchd=/sbin/launchd instead of a patch, as it looked simpler to me. fixed for both packages.
(In reply to comment #3) > I went with --with-launchd=/sbin/launchd instead of a patch, as it looked > simpler to me. > > fixed for both packages. That doesn't work for me: libX11 and libxcb will be compiled without launchd support. However, "--with-launchd" works as documented. Also there seems to be typo in libX11 ebuild: ${CHOST} == *-darwin} should probably be ${CHOST} == *-darwin* Reopening
The problem here is that the --with-launchd configure argument doesn't take a file or path instead it takes one of auto, yes, or no. The default is auto, which fails when sbin isn't on the PATH, as Johan notes. It worked for me when I used --with-launchd=yes instead of --with-launchd=/sbin/launchd Note that this change has to be made for both libX11 and libxcb to properly recognize the launchd DISPLAY variable. Also, don't forget the CHOST fix that Johan mentions in comment 4. I needed to do that too in order to get things working.
that means you still need PATH modifications then, do you?
No PATH changes are required. When --with-launchd is set to yes, no checking at all is done. The feature is just enabled. I don't know about all of the #ifdefs in the code but at least some of them just add an additional case for the launchd-style DISPLAY variables (e.g. /tmp/launch-xyz123/org.macosforge.xquartz:0).
Fixed by upstream within hours of reporting. Impressive! https://bugs.freedesktop.org/show_bug.cgi?id=29028
Ok, nice! I committed the with-launchd (no arguments) yesterday, which should fix this bug for the moment, next release our hacks should be thrown away then
