ghc-pkg ignores library dirs

[as49]

Hi,

I'm installing several packages in sequence. The first
package specified /usr/local/lib in the library_dirs
field. The .o file is built correctly. The next package
depends on the first package. To reduce the size of the
command line of any build with the second package, I
filter out all flags that are already in the first
package. Doing this, the .o file of the second package
cannot be built since ghc-pkg does not include the
library path of the first package when it searches for
the .a file.

I think that adding only those flags that are needed in
addition to some other dependent package is a
reasonable thing to do, so I would like to see ghc-pkg
search on the library paths of all dependant packages.

Thanks,
Axel.

[simonmar]

Logged In: YES 
user_id=48280

Just to check I've understood: you have a package that
includes a library foo.a, but the directory containing foo.a
does not appear in the library_dirs field of the package? 
I'd say you really ought to include the directory in
library_dirs.

[as49]

Logged In: YES 
user_id=489164

Yes, that is correct.

What is weird is that letting ghc-pkg build an .o file
breaks installation. My setup in which the second package
uses the include paths of the package it depends upon seems
to be sensible and it would work if it weren't for the .o
file creation.

I guess I just wanted to air that. I would be really good to
see the .o file go and ghci use the .a file. It breaks
horribly on Solaris when ghc-pkg uses the Solaris linker
which doesn't understand --whole-archive .

I'll close the bug then.
Axel.

[simonmar]

Logged In: YES 
user_id=48280


I deduce from your message that you're using ghc-pkg --force
--auto-ghci-libs.  Firstly, if you omit --force, then
ghc-pkg will correctly flag an error that the .a file can't
be found among library_dirs.  Secondly, you can avoid
creation of the .o file by omitting --auto-ghci-libs from
the ghc-pkg command line.

I'm aware that --force is needed when you run ghc-pkg before
actually installing the package (that's what it's for, really).

I agree that GHCi really should be able to use the .a file.
 However, even better would be for both GHC and GHCi to use
.so libraries - that's more likely to happen, actually.