On Fri, 2007-12-28 at 11:40 -0800, Bryan O'Sullivan wrote:
Duncan Coutts wrote:
Usually you would use "ld-options:" but in this case that will not help you since your flag really is for ghc. I'm not sure what you want to do is currently possible, except perhaps by passing --ghc-option=-pgmlg++ at configure time, but that's not very convenient.
Yeah. Alas!
Aye :-(
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`
ld-options should help here, and you could use Setup.hs to call llvm-config.
It has a weird side effect. I'm preprocessing some files using hsc2hs, and Cabal is using ld-options to link the little C program built as an intermediate product by hsc2hs. Is this expected?
Yes.
I'd have thought that program would be completely standalone, since pretty much all it does is call printf and fputs.
It's essential. hsc2hs compiles a C program that references things in the header files you're importing, linking that program to run it requires linking to the appropriate C libs. Though admittedly it's not clear to my why it should reference the C functions and thus have to link to the libs, but whenever I've tried without (eg in the gtk2hs build system) I get linker errors.
This causes further problems. Even if I pass --ghc-option=-pgmlg++ to "setup configure", it seems to only be used for compilation, not linking. I thus have to add -lstdc++ as an ld-option.
It should be used when linking an executable since we call ghc to do that. So I'm a bit confused about what's going on there. Any more details? However that doesn't help much if you're building a library that needs to be linked using the C++ compiler. That's just not going to work at all since you cannot propagate ghc options in packages to be used when compiling/linking programs that use the package.
The second problem is that preprocessing becomes very slow, since the LLVM libraries are huge. It takes longer to preprocess two source files than to build the entire library.
Why is that? Because linking the hsc2hs temporary executables with the LLVM libs takes a long time?
In order to make progress, I suppose I could either hard-code a dependency on g++ (aka -lstdc++) or try to figure out the extra libraries that the C++ runtime needs and add those as ld-options. Neither way seems especially satisfactory :-(
I think the second is much more likely to work in the long run. In my little experiment with gcc/g++ it seems that indeed all you need is -lstdc++ which translates to "extra-libraries: stdc++" in the .cabal file. g++ -c foo.c++ -o foo.o gcc foo.o -o foo -lstdc++ Duncan