#1477: ghci shouldn't link entire package
------------------------------+---------------------------------------------
Reporter: igloo | Owner:
Type: feature request | Status: new
Priority: normal | Milestone: 6.8
Component: GHCi | Version: 6.6.1
Severity: normal | Keywords:
Difficulty: Unknown | Os: Unknown
Testcase: | Architecture: Unknown
------------------------------+---------------------------------------------
In this thread: http://www.haskell.org/pipermail/glasgow-haskell-users
/2007-January/011839.html
Alistair Bayley requests that ghci only link against parts of a package
that are actually needed (like ld does) as:
{{{
With Takusen, all modules, including the DBMS-specific modules, are
compiled into a single library. At present we have 3 DBMS's: Sqlite,
Oracle, and PostgreSQL. For example, suppose you had just the Oracle
DBMS client libraries installed, and you write a program which only uses
the Oracle modules from Takusen. When you link, the gnu ld program
attempts to resolve the symbols in only the modules that you've used.
You don't need to have PostgreSQL or Sqlite installed, and the linker
ignores these modules from the package archive. This is quite nice,
because we can distribute the entire library as a single package, and it
will work even if the user does not have all of the DBMS client
libraries installed.
In contrast, when ghci (or runhaskell) attempts to link it tries to
resolve all of the symbols in the PostgreSQL and Sqlite modules, and
fails because you don't have them installed.
The result is that a user of Takusen can't easily use the library with
ghci/runhaskell "out of the box", unless they have the full set of DBMS
client libraries installed. There are a couple of workarounds, but
they're both a bit fiddly, so it'd be nicer (from my POV) if the ghci
linker behaved like gnu ld.
}}}
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1477>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
_______________________________________________
Glasgow-haskell-bugs mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
