After some searching I narrowed down the issue to /usr/lib/libcurses.so file. In Arch, this file contains INPUT(-lncursesw). If I change it to INPUT(libncursesw.so) or INPUT(/usr/lib/libncursesw.so) it works fine. Symlinking /usr/lib/libcurses.so to /usr/lib/libncursesw.so also works.

Change History (8)

I think GHC is trying to load /usr/lib/libcurses.so at runtime with dlopen, in order to run Template Haskell code in Data.Range.Range. It's not trying to link it with ld. So, this is a limitation of the system dlopen, and we are in "workaround" territory.

#2615 was from when GHC used its own custom loader rather than dlopen. I'm not eager to bring any of that back, but I guess we could try to detect a linker script if dlopen fails.

One thing (well, two things) I don't understand is where the dependency on /usr/lib/libcurses.so is coming from, and what kind of dependency it is exactly. Who is loading /usr/lib/libcurses.so: does dlopen load dependencies for us, or do we track them ourselves and load them first? Maybe we can arrange things when we build the llvm-general-3.4.2.2 library so that the dependency is on the real shared object /usr/lib/libncursesw.so.

Oh, hmm, I actually looked at the code and we do already inspect the error string from dlopen and try to parse a linker script. The problem is that we don't support INPUT(-llibrary). I guess we can transform the name to liblibrary.so in that case?

I still would like to avoid incurring dependencies on .sos that are really linker scripts, if possible...