On Wed, May 29, 2013 at 9:40 AM, Kees Bleijenberg <k.bleijenberg@lijbrandt.nl> 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

allbery.b@gmail.com ballbery@sinenomine.net

unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net