in reply to Understanding Inline::C to call vendor libraries

undefined reference to `DPGetCtrlStatus'

Is there an import lib (.a or .lib file) for the dll ? If so - what is its name and where is it located ?
With that information, we can fix it so that we link to that library and resolve the undefined reference.

If you have only the dll, then (IIRC) with gcc you should be able to link directly to it using the MYEXTLIB config option: 
use Inline C => Config => MYEXTLIB => 'C:/Program Files/Common Files/P
+roduct/4.1/dptcpiphi.dll'

[download]
(I'm assuming that's the fully qualified path name of the dll.)

If that still doesn't resolve the undefined reference then we'll have to come up with something else.
There are other options such as creating the import library, or loading the dll with LoadLibrary - but see how you go with the above suggestions first.

Cheers,
Rob

Replies are listed 'Best First'.
Re^2: Understanding Inline::C to call vendor libraries
by murrayn (Sexton) on Jul 28, 2014 at 07:08 UTC
    Thanks for your perserverance Rob. There's only the dll file. I've tried various permutations and combinations of Config statements and I've moved the dll file into the same folder as my Perl code to try to eliminate path issues. I need inspiration!
[reply]
      I've moved the dll file into the same folder as my Perl code to try to eliminate path issues

      It's better to put it in a folder that's already in the path, or add the location of the dll to the path: 
      set PATH=C:\wherever\it\is;%PATH%

      [download]
      At least then you know that it's going to be found when needed. (And if something wants to load it, but can't find it, you should get a pop-up that tells you quite clearly that the dll could not be found).

      Of course, *I* don't even know whether your dll exports the symbol in question. (Try running objdump -t dptcpiphi.dll >dump.txt 2>&1, then examine dump.txt to see what is being exported.)

      Probably best, anyway, that you create an import library and link to that: 
      gendef dptcpiphi.dll
dlltool --kill-at --input-def dptcpiphi.def --output-lib libdptcpiphi.
+a

      [download]
      You should already have dlltool (in MinGW/bin), but you probably won't have gendef.
      I know it comes with latest StrawberryPerl. If you want to get hold of it that way then I recommend either this 32-bit build or this64-bit build
      You'll want the same architecture (ie 32 or 64 bit) as the dll itself.
      Just unzip the Strawberry Perl package to whatever location you choose, navigate to that location, double click on 'portableshell.bat' and use the shell that pops up.
      You can probably get gendef elsewhere if you want to hunt around - and I think there's an alternative tool (whose name I can't remember).

      IMHO, you're better off using Strawberry Perl (which ships with gcc-4.8.2) - as opposed to using ActivePerl and gcc-3.4.5. You could, of course, instead use Strawberry's gcc-4.8.2 with ActivePerl, but I think you're better off with Strawberry Perl anyway (unless you're wanting to use a Microsoft compiler).

      Having created the import library, stick it in some location - say C:/my/libs. The correct invocation in the script is then: 
      use Inline C => Config => LIBS => '-LC:/my/libs -ldptcpiphi';

      [download]
      If that doesn't find the missing reference, then the dll apparently doesn't provide it.
      Let us know how you get on.

      Cheers,
      Rob
[reply]
[d/l]
[select]
        I ran the objdump above - there is no symbol table in the dll.

        I ran gendef and created a ".a" file and tried that path too without success.

        I went back to the vendor and grumbled about it all and they have provided a Java wrapper I can call to get to the API (theoretically) from any platform. Commercial time pressures mean that it's unlikely I'll be able to continue to explore the root cause on this one. (Maybe one day for my further education!)

        Thanks again for the excellent support.
        Murray

[reply]

In Section Seekers of Perl Wisdom