in reply to Re: XS with DLL
in thread XS with DLL

Aha, that explains the general problem, many thanks. I think I had a .a file lying around earlier, not thinking it mattered, and that's probably the reason that it worked once at random.

What I really want to do is to work with a third-party DLL for which I have a dll.h header file and an Exports.def file. I don't have a static version.

If there's a way to turn this information into a static simplelib.a, then I'm happy to do it. But I can't recompile the third-party DLL. I tried doing what it says at the bottom of https://cygwin.com/cygwin-ug-net/dll.html (dlltool), getting a libsimple.a. I can link standalone.o against this, and even run it, but I get zero output, so something is wrong.

Please excuse the basic questions (remember, g++ and Cygwin on Windows):

How exactly do I turn simplelib.dll into a proper libsimple.a?

How do I link against it stand-alone? I assume ... standalone.o -o standalone -L. -lsimple

How do I tie libsimple.a and glue.o (the XS .o) together into a proper DLL that is self-contained and can be moved around and loaded by DynaLoader?

I'm not against MakeMaker, but I couldn't get it to do what I wanted, and it's so big and intransparent that I decided to try to understand the actual steps first.

Replies are listed 'Best First'.
Re^3: XS with DLL
by syphilis (Archbishop) on Jun 05, 2014 at 15:33 UTC
    What I really want to do is to work with a third-party DLL for which I have a dll.h header file and an Exports.def file. I don't have a static version

    I don't know how you can create a static library with that, but you could create an import library for the dll:
    dlltool --kill-at --input-def your.def --output-lib lib_choose_a_name. +a
    Then you need to link to lib_choose_a_name.a when building the project.
    I don't know how to link the XS code to that import library without using ExtUtils::MakeMaker.

    The dll will still be need to be found at runtime (so it needs to be in the path or the cwd) but the code in the XS file you originally presented should then need no modification - assuming, of course, that "dll.h" contains the declaration of the "own_function" function (and that your dll exports that function).

    Cheers,
    Rob

      Thanks, Rob. I eventually figured out where DynaLoader was looking for simplelib.dll when it was loading glue.dll, and it was not where glue.dll was located... The fix was to chdir to the directory of glue.dll, rather than passing a full path to DynaLoader.

      Thanks again. I hope I'll never have to think about linking like that again :-).