Coping with weirdo third party packages
bos at serpentine.com
Fri Dec 28 02:26:36 EST 2007
As part of the LLVM stuff, I've run into a few more stumbling blocks.
1. "ghc-options" only seems to be passed to GHC during compilation of a
library, not at link time when building an executable against an
installed copy of the library. As LLVM is written in C++, I need to
link using the C++ compiler instead of the C compiler. I'd like to get
"-pgml g++" into the linking phase somehow.
2. LLVM has some slightly unusual code building conventions: some code
is shipped as .o files, with the expectation that a program will do
something like this at link time:
g++ -o foo foo.o `llvm-config --ldflags --libs engine`
The llvm-config command prints stuff like this:
$ llvm-config --libs engine
/usr/lib/LLVMInterpreter.o /usr/lib/LLVMExecutionEngine.o -lLLVMTarget
-lLLVMCore -lLLVMSupport -lLLVMbzip2 -lLLVMSystem
Notice the absolute paths to .o files in there. I had hoped to be able
to use Cabal to avoid the need for a user to run llvm-config --ldflags
or --libs, but I can't list the .o files in the extra-libraries section,
because Cabal slaps a "-l" in front:
/usr/bin/ld: cannot find -l/usr/lib/LLVMExecutionEngine.o
This could be patched easily enough.
3. It would also be nice to have a leading "-l" stripped off if present,
the better to feed the output of llvm-config directly into a .buildinfo
file without stuffing it through sed first.
Cabaliers, would you like some patches for 2 and 3 above? What should
we do about 1?
More information about the cabal-devel