Opened 10 years ago

Closed 2 years ago

Last modified 2 years ago

#1883 closed bug (fixed)

GHC can't find library using "short" name

Reported by: m4dc4p Owned by: Phyx-
Priority: lowest Milestone: 8.0.1
Component: Compiler Version: 6.6.1
Keywords: link library windows Cc:
Operating System: Windows Architecture: x86
Type of failure: None/Unknown Test Case:
Blocked By: #3658 Blocking:
Related Tickets: #2283 #3242 #1883 #7097 Differential Rev(s): Phab:D1310
Wiki Page:

Description

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

Change History (29)

comment:1 Changed 10 years ago by duncan

difficulty: Unknown

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.

comment:2 Changed 10 years ago by 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."

comment:3 in reply to:  2 Changed 10 years ago by duncan

Replying to m4dc4p:

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

No.

comment:4 Changed 10 years ago by igloo

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

comment:5 Changed 10 years ago by igloo

Milestone: 6.8 branch

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.

comment:6 Changed 9 years ago by igloo

Milestone: 6.8 branch6.10 branch

comment:7 Changed 9 years ago by 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.

comment:8 Changed 9 years ago by igloo

Milestone: 6.10 branch6.12 branch

comment:9 Changed 7 years ago by igloo

Milestone: 6.12 branch6.12.3

comment:10 Changed 7 years ago by igloo

Milestone: 6.12.36.14.1
Priority: normallow

comment:11 Changed 7 years ago by igloo

Milestone: 7.0.17.0.2

comment:12 Changed 7 years ago by igloo

Milestone: 7.0.27.2.1

comment:13 Changed 6 years ago by igloo

Milestone: 7.2.17.4.1

comment:14 Changed 6 years ago by igloo

Milestone: 7.4.17.6.1
Priority: lowlowest

comment:15 Changed 5 years ago by nus

Type of failure: None/Unknown

Also see ticket #3242.

comment:16 Changed 5 years ago by nus

comment:17 Changed 5 years ago by nus

comment:18 Changed 5 years ago by igloo

Blocked By: 3658 added

comment:19 Changed 5 years ago by igloo

Milestone: 7.6.17.6.2

comment:20 Changed 5 years ago by morabbin

Bump; any changes?

comment:21 Changed 3 years ago by thoughtpolice

Milestone: 7.6.27.10.1

Moving to 7.10.1.

comment:22 Changed 3 years ago by thoughtpolice

Milestone: 7.10.17.12.1

Moving to 7.12.1 milestone; if you feel this is an error and should be addressed sooner, please move it back to the 7.10.1 milestone.

comment:23 Changed 3 years ago by thoughtpolice

Moving to 7.12.1 milestone; if you feel this is an error and should be addressed sooner, please move it back to the 7.10.1 milestone.

comment:24 Changed 2 years ago by thoughtpolice

Milestone: 7.12.18.0.1

Milestone renamed

comment:25 Changed 2 years ago by Phyx-

Owner: set to Phyx-

Assigning this to myself as this will be fixed once the fix for the test in #9907 or Phab:D1244 is pushed.

The reason this still doesn't work is that the code that Simon added won't be called in a few cases. This code was added in Linker.c which is called from Linker.hs. Linker.hs itself tries to find the library by just appending ".dll" to the name.

Eventually none of the methods will be able to find the DLL and we then the code assumes the Linker.c can find it, so it passes the short name to the addDLL function. Eventually addDLL tries lib%s.DLL but this will most of the time fail since LoadLibrary won't be able to find it because the extra-lib-dirs paths are never used by it.

comment:26 Changed 2 years ago by Phyx-

Differential Rev(s): Phab:D1310
Status: newpatch

comment:27 Changed 2 years ago by Thomas Miedema <thomasmiedema@…>

In 5d84110/ghc:

Add short library names support to Windows linker

Make Linker.hs try asking gcc for lib%s.dll as well, also changed tryGcc
to pass -L to all components by using -B instead. These two fix
shortnames linking on windows.

re-enabled tests: ghcilink003, ghcilink006 and T3333
Added two tests: load_short_name and enabled T1407 on windows.

Reviewed By: thomie, bgamari

Differential Revision: https://phabricator.haskell.org/D1310

GHC Trac Issues: #9878, #1407, #1883, #5289

comment:28 Changed 2 years ago by Phyx-

Resolution: fixed
Status: patchclosed

comment:29 Changed 2 years ago by m4dc4p

So awesome to see this fixed! nice work.

Note: See TracTickets for help on using tickets.