Coping with weirdo third party packages

Bryan O'Sullivan bos at
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 mailing list