Since OpenBSD always uses .so.major.minor I observe GHCi running into trouble when resolving -l on its own. The way it tries to find the shared object to load is by relying on `cc --print-file-name`. I see this: $ ghci -v -lc++ ... Search directories (gcc): *** systool:linker: *** gcc: cc -Wl,-z,wxneeded --print-file-name 'libc++.so' !!! systool:linker: finished in 0.00 milliseconds, allocated 0.059 megabytes *** systool:linker: *** gcc: cc -Wl,-z,wxneeded --print-file-name 'liblibc++.so' !!! systool:linker: finished in 0.00 milliseconds, allocated 0.054 megabytes *** systool:linker: *** gcc: cc -Wl,-z,wxneeded --print-file-name 'c++.lib'
Which never succeeds, because the only way this could work is if ghc knew the version number: % cc --print-file-name 'libc++.so.9.0' /usr/lib/libc++.so.9.0 It feels like I need to somehow convince cc --print-file-name to get in here: ports/devel/llvm/patches/patch-tools_lld_ELF_DriverUtils_cpp Would it be a good idea to extend clang's --print-file-name in such a way that both versioned and unversioned variations work? I.e. make the second command works the same as the first one below? % cc --print-file-name libc++.so.9.0 /usr/lib/libc++.so.9.0 % cc --print-file-name libc++.so libc++.so Thanks Greg
