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).as... 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:allbery.b@gmail.com] 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 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 allbery.b@gmail.com ballbery@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net