[GHC] #9498: GHC links against unversioned .so files

[GHC]

#9498: GHC links against unversioned .so files
-------------------------------------+-------------------------------------
        Reporter:  Kritzefitz        |                   Owner:
            Type:  feature request   |                  Status:  infoneeded
        Priority:  low               |               Milestone:
       Component:  Compiler (FFI)    |                 Version:  7.6.3
      Resolution:                    |                Keywords:  Debian
Operating System:  Linux             |            Architecture:
 Type of failure:  Other             |  Unknown/Multiple
      Blocked By:                    |               Test Case:
 Related Tickets:                    |                Blocking:
                                     |  Differential Revisions:
-------------------------------------+-------------------------------------
Changes (by thomie):

 * status:  new => infoneeded


Comment:

 Kritzefitz: thank you for your response.

 I don't think there isn't anything for GHC to do here, and I'm inclined to
 close as invalid. What is your opinion?

 Here's my understanding of what's happening. I'm keeping this linux only
 (`sudo apt-get install libcurl4-openssl-dev` and `cabal install curl`
 first):

 * The .cabal file of the curl package specifies `extra-libraries: curl`

 * After cabal installing curl, this stanza ends up in curl's ghc package
 file (check with `ghc-pkg describe curl | grep extra-libraries`)

 * When you make test.hs, ghc figures out that curl is required. It parses
 curl's ghc package file, and extracts the extra-libraries field. When it's
 time for linking, it then passes `-lcurl` to the linker.

 * Since the linker wasn't told which version of curl it should find, it
 searches for a file `libcurl.so` in any of the system lib directories. On
 Debian/Ubuntu, as you mentioned, this unversioned file (symbolic link) is
 only present after installing a curl `-dev` package (1).

 * The linker then follows the symbolic link, and produces a binary that
 //is// linked to a versioned .so file (`libcurl.so.4` in my case). This is
 good, because that means that users of the binary will not need the `-dev`
 package for curl to be installed, but just the runtime package will do.

 The linker can be also be told to look for a specific file, by using
 `-l:filename` instead of `-lname` (see `man ld` and search for
 `--library=`). This `filename` is necessarily platform specific (e.g. dll
 on Windows), but cabal and ghc support this format in principal (though
 there seems to be a bug when doing this via ghci).

 Here's what I've tried:

 * cabal get curl && cd curl-1.3.8
 * # edit curl.cabal and change `extra-libraries: curl` to `extra-
 libraries: libcurl.so.4`
 * cabal install
 * sudo apt-get remove libcurl4-openssl-dev
 * # verify that libcurl.so is no longer present
 * # change to directory with your test.hs
 * ghc test.hs

 It works!

 Responding to your issue, either:

 1. Debian's should change its policy (1)
 2. or the curl library should be updated
 3. or users of the curl library should just install the curl -dev package
 (they are developers after all, not end users).



 (1) https://www.debian.org/doc/debian-policy/ch-sharedlibs.html#s
 -sharedlibs-dev

--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9498#comment:4>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler