Coping with weirdo third party packages
duncan.coutts at worc.ox.ac.uk
Sun Dec 30 05:16:21 EST 2007
On Sat, 2007-12-29 at 19:16 -0800, Bryan O'Sullivan wrote:
> 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.
This is linking an executable right?
> 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 :-)
GHC used to support doing that, putting ghc-options in package files but
the feature was removed because it was abused and led to much confusion
(eg adding extra pre-processors to all dependent packages).
> >> 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?
> >> 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.
It'll use g++/gcc on windows too I presume, so -lstdc++ ought to work
there too. Have you tried it?
> 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.
It's because we don't yet support building collections of related
packages very well. There have been suggestions that when we do support
that better that there should only be one library or executable
per .cabal file.
More information about the cabal-devel