id	summary	reporter	owner	description	type	status	priority	milestone	component	version	resolution	keywords	cc	os	architecture	failure	difficulty	testcase	blockedby	blocking	related
2429	error building full dll name to be loaded in ghci	jvl		"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)
"	bug	closed	normal	6.10.1	Driver	6.8.2	fixed	dll		Windows	Unknown/Multiple		Unknown