ghci command line option -l should accept either -llibrary or -l library (POSIX requirement)
According to POSIX, the -l option of GHCi should work with either the library name concatenated to the -l or as as separate argument immediately following the -l. At present it only works in the first case.
Examples of current behavior:
# failure (library name separated from -l)
hgolden@hbg-srv3 ~ $ ghci -l pcre
GHCi, version 7.0.1: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Loading package ffi-1.0 ... linking ... done.
Loading object (dynamic) ... failed.
<command line>: user specified .o/.so/.DLL could not be loaded (lib.so: cannot open shared object file: No such file or directory)
Whilst trying to load: (dynamic)
Additional directories searched: (none)
# success (library name concatenated with -l)
hgolden@hbg-srv3 ~ $ ghci -lpcre
GHCi, version 7.0.1: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Loading package ffi-1.0 ... linking ... done.
Loading object (dynamic) pcre ... done
final link ... done
Prelude> :q
Leaving GHCi.
(This is a very minor bug with a trivial workaround. However, it should be easy to fix.)
Compare how GCC handles -l. While the -l library form is discouraged, it is accepted.
Trac metadata
Trac field | Value |
---|---|
Version | 7.0.1 |
Type | Bug |
TypeOfFailure | OtherFailure |
Priority | normal |
Resolution | Unresolved |
Component | GHCi |
Test case | |
Differential revisions | |
BlockedBy | |
Related | |
Blocking | |
CC | |
Operating system | |
Architecture |