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 |