GHC can't find library using "short" name

[m4dc4p]

I wanted to build HDBC-postgresql 1.0.1[1] today, and ran into a problem where my test program would not load and instead gave this error:

  can't load .so/.DLL for: pq (addDLL: unknown error)

I traced this to the 'extra-libraries' directive in the .cabal file. It read

Extra-Libraries: pq

When I changed it to

Extra-Libraries: libpq

The error went away. Somehow "pq" is not enough to get "libpq.dll" loaded.

Note that building on Windows required some other changes.[2]

This was using Cabal 1.1

[1]  http://hackage.haskell.org/cgi-bin/hackage-scripts/package/HDBC-postgresql-1.0.1.0

[2] From  http://software.complete.org/hdbc/wiki/FrequentlyAskedQuestions

To build on Windows, you must specify where the postgresql include and library files are. Follow these two steps:

1. Ensure the files are NOT installed in a directory with spaces in the name (e.g. "C:\Program Files"). For example, install them in c:\pgsql.
2. Assuming postgresql is installed in C:\pgsql, add the following information to the .cabal file:

         include-dirs: C:\pgsql\include, C:\pgsql\include\server, .
         extra-lib-dirs: C:\pgsql\bin
   

   Notice the "." at the end of include-dirs to ensure the current directory is also searched. Also notice "bin" directory is specified in "extra-lib-dirs." This is important in the next step.
3. HDBC-postgresl depends on "libpa.dll" in the bin directory above. The .cabal file refers to the "pq", but that doesn't work on Windows. Change it to libpq like so:

Extra-Libraries: libpq

[duncan]

I've dealt with this problem in Gtk2Hs before. The issue is that the .dll name can differ from the static library name or the import library name.

For example gcc -lfoo will link with libfoo.a on windows (or foo.lib and probably some other variants too). The .a/.lib file knows exactly which dll this will correspond to at runtime. The gcc/ld linker bakes this information into the .exe so the windows dll will look for the right file. So the point is the name of the .dll need not match the name of the .a/.lib file.

So that's all well and good for the case of making a .exe and using the native linker. GHCi has more difficulty since it does not actually know the name of the dll at all since it does not read the static import lib. So it just has to guess based on the name of the library. Most windows dlls have exactly the same name as the import lib, but some that have been ported from unix use a "lib" prefix on their dll name.

The slightly hacky solution we implemented to make Gtk2Hs work nicely on windows was to add to ghc an extra field, "extra-ghci-libraries:" to the package registration file, so that ghci could use different names for the libraries than in the static case where we use the native linker.

[m4dc4p]

Is there a way to specify "extra-ghci-libraries" in the Cabal file? I couldn't find anything that seemed related, and it would be nice to be able to specify this so things "just work."

[duncan]

Replying to m4dc4p:

Is there a way to specify "extra-ghci-libraries" in the Cabal file?

No.

[igloo]

Is there something that GHC should(n't) do, or should this bug be moved to the Cabal trac?

[igloo]

After a short talk with Duncan I think we should be able to do something, although it might require ghci having to jump through hoops (find the .lib/.a file for the library in order to get the DLL name to load). I'll put it in the 6.8 branch milestone for now, although I'm not optimistic we'll unpick this before 6.10.

[simonmar]

This is not a complete fix, but I made the linker look for "libXXX.dll" in addition to "XXX.dll".

Wed Sep  3 11:49:51 GMT Daylight Time 2008  Simon Marlow <marlowsd@gmail.com>
  * Windows: print an error message in addDLL
  Also, look for libXXX.dll in addition to XXX.dll (see #1883, this
  isn't really a proper fix, but it'll help in some cases).
  And I tidied up the error message for a DLL load failure, though it's
  still a bit of a mess because addDLL is supposed to return a (static)
  string with the error message, but this isn't possible on Windows.

[nus]

Also see ticket #3242.

[morabbin]

Bump; any changes?