You are absolutely right, they do not seem to play along very well. Here's what I tried: $ cabal install --disable-library-vanilla --enable-shared ranges Resolving dependencies... Configuring ranges-0.2.4... Preprocessing library ranges-0.2.4... Building ranges-0.2.4... [1 of 1] Compiling Data.Ranges ( Data/Ranges.hs, dist/build/Data/Ranges.dyn_o ) Data/Ranges.hs:74:7: Warning: This binding for `x' shadows the existing binding bound at Data/Ranges.hs:72:13 cabal: <command line>: Failed to load interface for `Data.Ranges': Use -v to see a list of the files searched for. cabal: Error: some packages failed to install: ranges-0.2.4 failed during the building phase. The exception was: ExitFailure 1 2011/11/3 Yves Parès :

Apparently, disabling library vanilla causes GHC not to generate the ".hi" files : For instance when 'cabal install quickcheck --disable-library-vanilla':

Registering QuickCheck-2.4.1.1... cabal: QuickCheck-2.4.1.1: file Test/QuickCheck/All.hi is missing (use --force to override) QuickCheck-2.4.1.1: file Test/QuickCheck/Function.hi is missing (use --force to override) [...] override) QuickCheck-2.4.1.1: file Test/QuickCheck/State.hi is missing (use --force to override) QuickCheck-2.4.1.1: file Test/QuickCheck/Exception.hi is missing (use --force to override) QuickCheck-2.4.1.1: cannot find libHSQuickCheck-2.4.1.1.a on library path (use --force to override)

2011/11/3 Ivan Perez

...

2011/11/2 Yves Parès :

...

Hello,

When I tell cabal-install to build shared libraries (with "Shared: True" in .cabal/config), it doubles the libraries installation time since it compiles them twice, since it seems that is what GHC's flag "-shared" does. Is there a way to generate only the .so and not the the .a libs?

--disable-library-vanilla

   Do not build ordinary libraries. This is useful in conjunction with --enable-library-profiling    to build only profiling libraries, rather than profiling and ordinary libraries.

Haven't tried it myself. Maybe it works in combination with --enable-shared?

From: http://haskell.org/ghc/docs/7.0.4/html/Cabal/builders.html

...

Furthermore, I have the impression that the executables compiled by cabal-install are always linked statically... Can I tell cabal-install to activate the GHC's flag "-dynamic" for executables?

The following two trac tickets mention a separate flag, named --enable-executable-dynamic:

http://hackage.haskell.org/trac/hackage/ticket/600 http://hackage.haskell.org/trac/hackage/ticket/869

If that doesn't work, you can probably pass some argument to ghc with --with-ghc-option

Cheers, Ivan

...

Thanks.

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe