Coping with weirdo third party packages

[Bryan O'Sullivan]

Duncan Coutts wrote:

>> 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?

Not really.  It's definitely not in the command line at link time.
Beyond inspecting the code to see why it's not happening, I don't know
what else might be useful to you.

> 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.

That's a shame - I'd hoped it was exactly what would happen :-)

>> 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?

Right.

>> 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.

> I think the second is much more likely to work in the long run.

Yeah, it's just brittle.  gcc is ubiquitous on Unixy platforms, but LLVM
runs on Windows too, and my Windows compiler fu is weak.

I think that a README will have to suffice for now.

By the way, is there a reason why a .cabal file can specify multiple
executables, but only one library?  LLVM wants to be built in a modular
fashion to minimise the number of dependencies, and it would be nice to
be able to put llvm-common, llvm-core, and llvm-engine all in a single
.cabal file, each with different ld-options.

	<b