Opened 10 years ago

Closed 21 months ago

#1477 closed feature request (wontfix)

ghci shouldn't link entire package

Reported by: igloo Owned by:
Priority: normal Milestone:
Component: Runtime System (Linker) Version: 6.6.1
Keywords: Cc:
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: None/Unknown Test Case:
Blocked By: Blocking:
Related Tickets: Differential Rev(s):
Wiki Page:


In this thread: 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.

Change History (4)

comment:1 Changed 10 years ago by igloo

Milestone: 6.8 branch_|_

comment:2 Changed 9 years ago by simonmar

Architecture: UnknownUnknown/Multiple

comment:3 Changed 9 years ago by simonmar

Operating System: UnknownUnknown/Multiple

comment:4 Changed 21 months ago by ezyang

Component: GHCiRuntime System (Linker)
Resolution: wontfix
Status: newclosed
Type of failure: None/Unknown

This would cause major complications for GHCi, as you would need to somehow be able to load the other symbols lazily when you loaded a new library that actually needed them. Additionally, dynamic linking would have the same problem unless the platform supports lazy dynamic loading. The indicated solution is to split the package into three.

Note: See TracTickets for help on using tickets.