Coping with weirdo third party packages

[Duncan Coutts]

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