[GHC] #2429: error building full dll name to be loaded in ghci

[GHC-2]

#2429: error building full dll name to be loaded in ghci
------------------------+---------------------------------------------------
    Reporter:  jvl      |       Owner:        
        Type:  bug      |      Status:  new    
    Priority:  normal   |   Component:  Driver
     Version:  6.8.2    |    Severity:  normal
    Keywords:  dll      |    Testcase:        
Architecture:  Unknown  |          Os:  Windows
------------------------+---------------------------------------------------
 problem encountered ghc 6.8.2 on windows XP.

 This problem was identified whilst trying to load the wxHaskell dll into
 ghci.
 The wxHaskell dll is named wxc-msw2.6.4-0.10.3.dll and will not load into
 ghci,
 the following error is encountered

 {{{
 >ghci -fglasgow-exts -lwxc-msw2.6.4-0.10.3
 GHCi, version 6.8.2: http://www.haskell.org/ghc/  :? for help
 Loading package base ... linking ... done.
 Loading object (dynamic) wxc-msw2.6.4-0.10.3 ... failed.
 Dynamic linker error message was:
    addDLL: unknown error
 Whilst trying to load:  (dynamic) wxc-msw2.6.4-0.10.3
 Directories to search are:
 : user specified .o/.so/.DLL could not be loaded.
 }}}

 yet if we rename the dll

 {{{
 >ghci -fglasgow-exts -lwxc-msw2.6.4-0.10
 GHCi, version 6.8.2: http://www.haskell.org/ghc/  :? for help
 Loading package base ... linking ... done.
 Loading object (dynamic) wxc-msw2.6.4-0.10 ... done
 final link ... done
 Prelude>
 }}}

 i.e. the final .3.dll causes the problem, exceeding some limit? There
 appears to be an error in the parsing and construction of the full dll
 name.
 i.e. ghci postfix's a .dll adds the path etc, to the base name, but in the
 above, it can't handle the extra ".3" in the name.

 ghc in compile mode does not have this error.

 The above can be verified by constructibe a dummy dll using the following
 c file,
 then renaming it appropriately, file wxc.cpp:

 {{{

 #define ROBEXP __declspec(dllexport)


 void ROBEXP foo_addref(int* f){ }
 void ROBEXP foo_release(int* f){ }
 }}}

 as follows

 {{{
 >cl /LD /MD wxc.cpp

 >ghci -fglasgow-exts -lwxc
 GHCi, version 6.8.2: http://www.haskell.org/ghc/  :? for help
 Loading package base ... linking ... done.
 Loading object (dynamic) wxc ... done
 final link ... done

 }}}

 rename and test

 {{{
 >rename wxc.dll wxc-msw2.6.4-0.10.3.dll

 >ghci -fglasgow-exts -lwxc-msw2.6.4-0.10.3
 GHCi, version 6.8.2: http://www.haskell.org/ghc/  :? for help
 Loading package base ... linking ... done.
 Loading object (dynamic) wxc-msw2.6.4-0.10.3 ... failed.
 Dynamic linker error message was:
    addDLL: unknown error
 Whilst trying to load:  (dynamic) wxc-msw2.6.4-0.10.3
 Directories to search are:
 : user specified .o/.so/.DLL could not be loaded.
 }}}

 again the same load error

 A number of other points ...

  * dll load error messages
  * dll load name stuffing

 == error messages ==
 The same error message "addDLL: unknown error" will apear regardless of
 whether the error
 is a genuine "unknown" error or not. The load error reporting should at
 least distinguish
 between not being able to locate the dll and other errors, for example,
 lets give the load
 a spurious name

 {{{
 >ghci -fglasgow-exts -lwxc-msw2.6.4-X
 GHCi, version 6.8.2: http://www.haskell.org/ghc/  :? for help
 Loading package base ... linking ... done.
 Loading object (dynamic) wxc-msw2.6.4-X ... failed.
 Dynamic linker error message was:
    addDLL: unknown error
 Whilst trying to load:  (dynamic) wxc-msw2.6.4-X
 Directories to search are:
 : user specified .o/.so/.DLL could not be loaded.
 }}}

 OK, now lets create a bad dll

 {{{
 >cp wxc.cpp wxc-msw2.6.4-X.dll
 }}}

 {{{
 >ghci -fglasgow-exts -lwxc-msw2.6.4-X

 GHCi, version 6.8.2: http://www.haskell.org/ghc/  :? for help
 Loading package base ... linking ... done.
 Loading object (dynamic) wxc-msw2.6.4-X ... failed.
 Dynamic linker error message was:
    addDLL: unknown error
 Whilst trying to load:  (dynamic) wxc-msw2.6.4-X
 Directories to search are:
 : user specified .o/.so/.DLL could not be loaded.
 }}}

 so we can't even distinguish between a missing dll and a bad one !

 == name stuffing ==

 Also, if possible wouldn't it be better for ghci to display the same
 behaviour as gcc in treatment of dll names i.e. it will postfix .dll, but
 if that fails it will try the supplied name without any extension, so
 something
 like the following will work.

 {{{
 ghci -lsomelib.dll
 }}}

 a somewhat related issue #1883 can be treated in the same way, i.e.
 generate a
 set of possible target dll full names, by prefixing, postfixing, or in
 pseudo
 haskell in the list monad

 {{{
 names base = do
   prefix <- all_possible_prefix_including_null
   postfix <- all_possible_postfix_including_null
   return (prefix++base++postfix)
 }}}

 then test each one for load, (gcc does something very similar when
 searching for .a libraries)

--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2429>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
_______________________________________________
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@...
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

[GHC-2]

#2429: error building full dll name to be loaded in ghci
---------------------+------------------------------------------------------
 Reporter:  jvl      |          Owner:        
     Type:  bug      |         Status:  new    
 Priority:  normal   |      Milestone:  6.10.1
Component:  Driver   |        Version:  6.8.2  
 Severity:  normal   |     Resolution:        
 Keywords:  dll      |     Difficulty:  Unknown
 Testcase:           |   Architecture:  Unknown
       Os:  Windows  |  
---------------------+------------------------------------------------------
Changes (by igloo):

  * difficulty:  => Unknown
  * milestone:  => 6.10.1

Comment:

 Thanks for the report

--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2429#comment:1>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
_______________________________________________
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@...
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

[GHC-2]

#2429: error building full dll name to be loaded in ghci
---------------------+------------------------------------------------------
 Reporter:  jvl      |          Owner:        
     Type:  bug      |         Status:  closed
 Priority:  normal   |      Milestone:  6.10.1
Component:  Driver   |        Version:  6.8.2  
 Severity:  normal   |     Resolution:  fixed  
 Keywords:  dll      |     Difficulty:  Unknown
 Testcase:           |   Architecture:  Unknown
       Os:  Windows  |  
---------------------+------------------------------------------------------
Changes (by simonmar):

  * status:  new => closed
  * resolution:  => fixed

Comment:

 I couldn't reproduce the reported bug (with HEAD), but I did improve the
 error messages.

 {{{
 Wed Sep  3 11:49:51 GMT Daylight Time 2008  Simon Marlow
 <marlowsd@...>
   * 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.
 Shall I push this patch? (1/2)  [ynWvpxdaqjk], or ? for help:
 Wed Sep  3 11:50:18 GMT Daylight Time 2008  Simon Marlow
 <marlowsd@...>
   * sysErrorBelch: don't put an extra \n on Windows
 }}}

--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2429#comment:2>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
_______________________________________________
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@...
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs