On 8/7/25 02:40, Greg Troxel wrote:
PHO <pho%cielonegro.org@localhost> writes:Perhaps the ${WRKDIR} pointing to /tmp is what is triggering the bug? I would love to test my hypothesis but I'm really busy right now. I hope I can do it after a few days or a week, and hope I can track down the real cause.That seems like a good guess. There are known problems on mac, not about haskell, when $CWD and `pwd -P` do not match. I wonder if there is an attempt to filter out rpath that matches WRKDIR and it's not matching on symlinks.
My guess was correct. Setting WRKOBJDIR to /tmp, or any directories under /tmp, triggers the bug.
Some Haskell modules are internally split into several internal libraries, and each library is built as a regular shared library (.so or .dylib). It appears Cabal, the module build system, has a bug that I haven't been aware of. Suppose a module consists of 3 libraries A, B, and C. If B depends on A, the system correctly injects an rpath to the installation directory of A into B. But if C depends on B, it injects an rpath to the installation directory of B and another rpath to the *build* directory of A into C, which is very wrong.
However, the bug doesn't rise up to the surface in the default setup because our {c,}wrappers removes -Wl,-rpath to the build directory. It only becomes a problem when WRKOBJDIR is somewhere under /tmp because our mk/haskell.mk does this:
# When a Template Haskell splice is to be evaluated by a dynamically-linked
# GHC, it first compiles the splice and creates a .so file like
# /tmp/ghc_XXXX/libghc_XX.so, then it dlopen's it. When the source file
# contains more than one splice, subsequent splices will refer to previous
# ones via "-L/tmp/ghc_XXXX -Wl,-rpath,/tmp/ghc_XXXX -lghc_XX". This means
# /tmp/ghc_* must be protected from getting removed by our wrappers. We
# also want to be explicit about the path to be chosen for temporary files.
CONFIGURE_ARGS+= --ghc-options=-tmpdir\ ${TMPDIR:U/tmp:Q}
BUILDLINK_PASSTHRU_DIRS+= ${TMPDIR:U/tmp:S,/$$,,}
Template Haskell is like CPP macro but is far more powerful. It is a snippet of code written in Haskell itself which manipulates and/or generates some Haskell AST. Those snippets are compiled and executed during build.
One way to work around the bug is to use something like /tmp/ghc as the temporary directory for Template Haskell so that it won't be a parent of WRKOBJDIR, but this of course isn't a proper fix. So I'm trying to track down the root cause now...