using a win32 dll (Happy too soon)

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

using a win32 dll (Happy too soon)

Kees Bleijenberg

Unfortunatly the proposed solutions didn’t work after all (It worked once, I think, but…)

 

Here again the problem:

glasPng.dll is a Delphi dll with the function getPngVersion in it. Calling convention  is stdCall. I want to use this dll. The code:

{-# LANGUAGE ForeignFunctionInterface #-}

module Main(

      main

)

 

where

import Control.Monad

import Foreign.C

import Foreign.Marshal.Alloc

import Foreign.Marshal.Array

import System.Win32.Types

 

foreign import stdcall "getPngVersion"  getPngDllVersion :: IO CString

 

main :: IO ()

main = do

         s <- getPngDllVersion

         putStrLn (show s)

 

glasPng.dll is in the Windows path (I’ve checked it).

If I compile with ghc --make testGlasPng.hs –lglasPng I get: ….\ld.exe: cannot find –lglasPng. Collect 2: ld returned 1 exit status.

Ld can’t find lglasPng (with the l in front, does it trim the l?). Why? Okay I try

ghc --make testGlasPng.hs –L<path to glasPng.dll> I get:

testGlasPng.o: fake: (.text + 0x82) :undefined reference to ‘getPngVersion@0’. I think it has found  the dll, but it complains the function is not in the dll. But TDump and Dll export viewer say getPngVersion is in the dll.

 

I run ghc on a 64 bits computer. The dll is 32 bits. Is that the problem?

 

What can I do?

Kees


_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: using a win32 dll (Happy too soon)

Robert Jakob
> If I compile with ghc --make testGlasPng.hs -lglasPng I
> get: ..\ld.exe: cannot find -lglasPng. Collect 2: ld returned 1 exit
> status.
>
> Ld can't find lglasPng (with the l in front, does it trim the l?).
> Why? Okay I try
>
> ghc --make testGlasPng.hs -L<path to glasPng.dll> I get:
>
> testGlasPng.o: fake: (.text + 0x82) :undefined reference to
> 'getPngVersion@0'. I think it has found  the dll, but it complains the
> function is not in the dll. But TDump and Dll export viewer say
> getPngVersion is in the dll.

I think you should use both -L and -l.
ghc --make testGlasPng.hs -L/path/to/folder/where/glasPng/is -lglasPng

-L should point to the folder, NOT the dll itself.

Hope this helps.

R.

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: using a win32 dll (Happy too soon)

Brandon Allbery
In reply to this post by Kees Bleijenberg
On Wed, May 29, 2013 at 9:40 AM, Kees Bleijenberg <[hidden email]> wrote:

If I compile with ghc --make testGlasPng.hs –lglasPng I get: ….\ld.exe: cannot find –lglasPng. Collect 2: ld returned 1 exit status.

Ld can’t find lglasPng (with the l in front, does it trim the l?). Why? Okay I try


It's reproducing the thing passed to it, rather than outputting both the dll and implib versions that it actually looks for. Same happens on unixlikes where it's looking for a .so/.dylib/whatever or a .a.

ghc --make testGlasPng.hs –L<path to glasPng.dll> I get:


Not quite right; -L identifies a *directory* to search, then you must specify the actual filename afterward.
 

testGlasPng.o: fake: (.text + 0x82) :undefined reference to ‘getPngVersion@0’. I think it has found  the


This just means it can't find the symbol; it does not mean it necessarily found the DLL.
 

I run ghc on a 64 bits computer. The dll is 32 bits. Is that the problem?


That can certainly be a problem, yes, and is likely why it wasn't found with the first one. But it's not so much what kind of machine you are on, as what kind of ghc you are using: a 64-bit ghc cannot link 32-bit libraries, and vice versa. But a 32-bit ghc and toolchain will work fine on a 64-bit system, aside from not linking 64-bit DLLs. 

--
brandon s allbery kf8nh                               sine nomine associates
[hidden email]                                  [hidden email]
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: using a win32 dll (Happy too soon)

Kees Bleijenberg
Brandon, thank you for your explanation.
I got it working with: ghc --make testGlasPng.hs -LD:\glas\dlls -lglasPng. It needs both the -L and the -l argument. The dll is in the PATH. I don't understand why it needs the -L argument. I'll figure this out later. If I use -lglasPng.dll (additional .dll) it doesn't work either.
Now everything works fine. I can pass strings from haskell to the dll and vice versa.

Kees

----------
On Wed, May 29, 2013 at 9:40 AM, Kees Bleijenberg <[hidden email]> wrote:
If I compile with ghc --make testGlasPng.hs –lglasPng I get: ….\ld.exe: cannot find –lglasPng. Collect 2: ld returned 1 exit status.
Ld can’t find lglasPng (with the l in front, does it trim the l?). Why? Okay I try

It's reproducing the thing passed to it, rather than outputting both the dll and implib versions that it actually looks for. Same happens on unixlikes where it's looking for a .so/.dylib/whatever or a .a.

ghc --make testGlasPng.hs –L<path to glasPng.dll> I get:

Not quite right; -L identifies a *directory* to search, then you must specify the actual filename afterward.
 
testGlasPng.o: fake: (.text + 0x82) :undefined reference to ‘getPngVersion@0’. I think it has found  the

This just means it can't find the symbol; it does not mean it necessarily found the DLL.
 
I run ghc on a 64 bits computer. The dll is 32 bits. Is that the problem?

That can certainly be a problem, yes, and is likely why it wasn't found with the first one. But it's not so much what kind of machine you are on, as what kind of ghc you are using: a 64-bit ghc cannot link 32-bit libraries, and vice versa. But a 32-bit ghc and toolchain will work fine on a 64-bit system, aside from not linking 64-bit DLLs.

--
brandon s allbery kf8nh                               sine nomine associates
[hidden email]                                  [hidden email]
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net


_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: using a win32 dll (Happy too soon)

Brandon Allbery
In reply to this post by Brandon Allbery
On Thu, May 30, 2013 at 3:15 AM, Kees Bleijenberg <[hidden email]> wrote:
argument. The dll is in the PATH. I don't understand why it needs the -L argument. I'll figure this out later. If I use -lglasPng.dll (additional .dll) it doesn't work either.

Unix has standard places to install and search for libraries; Windows doesn't, and almost every library that doesn't come with your build system will need at least one -L option to tell the linker where to find it.

As I mentioned in my first message, it looks for multiple file names with -l: first it tries a .dll, then it tries a .lib (static library or import library for older DLLs). It does this mechanically; if you also include the .dll suffix, then it looks for library.dll.dll and library.dll.lib, which is almost certainly wrong.

--
brandon s allbery kf8nh                               sine nomine associates
[hidden email]                                  [hidden email]
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: using a win32 dll (Happy too soon)

Kees Bleijenberg
Brandon, thanks again for your explanation
Are you sure about the non existing search order for dynamic loaded dll’s?
I.e. http://msdn.microsoft.com/en-us/library/windows/desktop/ms682586(v=vs.85).aspx#standard_search_order_for_desktop_applications says there is a search order, starting with the current directory (I think).
I don’t understand why the linker needs to see the dll anyway. I think you should be able to develop a executable (that later will use a dll), while the dll isn’t there at link time. The dll only has to be there at runtime (kind of lazy loading..). Or maybe not even that. I.e. the executable uses the dll only in special cases and the user can download this dll if he wants it. This is possible in Delphi. Is Haskell dynamic loading more limited?

Kees

Van: Brandon Allbery [mailto:[hidden email]]
Verzonden: donderdag 30 mei 2013 16:13
Aan: Kees Bleijenberg
CC: haskell-cafe
Onderwerp: Re: [Haskell-cafe] using a win32 dll (Happy too soon)

On Thu, May 30, 2013 at 3:15 AM, Kees Bleijenberg <[hidden email]> wrote:
argument. The dll is in the PATH. I don't understand why it needs the -L argument. I'll figure this out later. If I use -lglasPng.dll (additional .dll) it doesn't work either.

Unix has standard places to install and search for libraries; Windows doesn't, and almost every library that doesn't come with your build system will need at least one -L option to tell the linker where to find it.

As I mentioned in my first message, it looks for multiple file names with -l: first it tries a .dll, then it tries a .lib (static library or import library for older DLLs). It does this mechanically; if you also include the .dll suffix, then it looks for library.dll.dll and library.dll.lib, which is almost certainly wrong.

--
brandon s allbery kf8nh                               sine nomine associates
[hidden email]                                  [hidden email]
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net


_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: using a win32 dll (Happy too soon)

Brandon Allbery
In reply to this post by Brandon Allbery
On Thu, May 30, 2013 at 11:46 AM, Kees Bleijenberg <[hidden email]> wrote:
Brandon, thanks again for your explanation
Are you sure about the non existing search order for dynamic loaded dll’s?
I.e. http://msdn.microsoft.com/en-us/library/windows/desktop/ms682586(v=vs.85).aspx#standard_search_order_for_desktop_applications says there is a search order, starting with the current directory (I think).

There is a search order. What I said is that there are no standard locations to install things. That is, every library package stows stuff in its own directory structure and no compiler can possibly know all the places it needs to look to find every library off in its own directory.
 
I don’t understand why the linker needs to see the dll anyway.

Because it's better to catch "that symbol doesn't exist" at build time instead of throwing an ugly error at runtime, among other things.
 
possible in Delphi. Is Haskell dynamic loading more limited?

There are ways to do that kind of dynamic linking; this is not one of them. C and C++ don't automatically dynload the way you're thinking either, because you should test for the DLL you're distributing (you are distributing it, right, not forcing the end user on a wild goose chase to find their own copy of the DLL, hoping it's the right/compatible version, and figure out where to put it so your program will run?) being the right one *when you build the program*, not defer that test until it is run.

If you think about it, this is very similar to doing your type checking at compile time instead of runtime. If you want lazy type checking, why are you using Haskell? If you want lazy library checking, why are you using a compiler?

--
brandon s allbery kf8nh                               sine nomine associates
[hidden email]                                  [hidden email]
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: using a win32 dll (Happy too soon)

Henk-Jan van Tuyl
In reply to this post by Brandon Allbery
On Thu, 30 May 2013 16:13:22 +0200, Brandon Allbery <[hidden email]>  
wrote:

> On Thu, May 30, 2013 at 3:15 AM, Kees Bleijenberg <
> [hidden email]> wrote:
>
>> argument. The dll is in the PATH. I don't understand why it needs the -L
>> argument. I'll figure this out later. If I use -lglasPng.dll (additional
>> .dll) it doesn't work either.
>>
>
> Unix has standard places to install and search for libraries; Windows
> doesn't, and almost every library that doesn't come with your build  
> system
> will need at least one -L option to tell the linker where to find it.

You could also try using the environment variable LIBRARY_PATH, see;
   http://www.haskell.org/haskellwiki/Windows#Tools_for_compilation

Regards,
Henk-Jan van Tuyl


--
Folding@home
What if you could share your unused computer power to help find a cure? In  
just 5 minutes you can join the world's biggest networked computer and get  
us closer sooner. Watch the video.
http://folding.stanford.edu/


http://Van.Tuyl.eu/
http://members.chello.nl/hjgtuyl/tourdemonad.html
Haskell programming
--

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe