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 _______________________________________________ cabal-devel mailing list [email protected] http://www.haskell.org/mailman/listinfo/cabal-devel
