Hello,
When mcookie is not found at configure time, we were failing to correctly
set HAS_COOKIE_MAKER and MK_COOKIE, which ends up causing startx to think it
should run a command called MK_COOKIE. The attached patch fixes this case.
Additionally, when MCOOKIE is set to a valid path, we need to prevent further
preprocessor expansion on the result. In particular, the mcookie path for Nix
and Guix contain what looks like the token "linux", which is #defined by
default in gcc and clang. The attached patch fixes this by ensuring that the
MCOOKIE value is quoted inside the post-processed source.
However, as you can see, the current mechanism requires dancing around three
layers of quoting and is exremely fiddly. Perhaps we should add a
--with-mcookie configure option instead, which would be more robust and
rationalize mcookie configuration with all the other --with-* settings we have.
This patch fixes two bugs in upstream mcookie detection: 1) If mcookie is not
detected, we still need to set HAS_COOKIE_HANDLER and MK_COOKIE, and 2) the
value for MK_COOKIE must be a string in order to disallow further preprocessor
expansions.
In particular for 2, if we fail to surround the path in quotes, our path
contains the token "linux", which gcc further expands, creating an invalid
path.
--- a/configure.ac 2025-03-08 16:48:34.476791744 +0900
+++ b/configure.ac 2025-03-08 16:48:30.208791623 +0900
@@ -157,8 +157,10 @@
fi
fi
if test "x$MCOOKIE" != x ; then
- STARTX_COOKIE_FLAGS='-DHAS_COOKIE_MAKER -DMK_COOKIE="$(MCOOKIE)"'
+ STARTX_COOKIE_FLAGS='-DHAS_COOKIE_MAKER -DMK_COOKIE="'"'"'$(MCOOKIE)'"'"'"'
AC_MSG_NOTICE([startx will depend on "$MCOOKIE" to generate xauth cookies])
+else
+ STARTX_COOKIE_FLAGS='-DHAS_COOKIE_MAKER -DMK_COOKIE='
fi
AC_SUBST(STARTX_COOKIE_FLAGS)
