[PD-dev] [leapmotion] 2.3.1 linking failure on Windows

[William Brent]

Hi again, I've got a successful build using cmake, but now I've run into
another issue. The external loads and works just fine in Pd on the windows
machine I compiled with, but fails on another machine with:

"leapmotion.dll: The specified module could not be found. (126)"

I know this is the error thrown when the necessary .dll is missing (in this
case, Leap.dll), but I have Leap.dll in the same directory as my
leapmotion.dll binary. Both machines are running 64-bit Windows 10 using Pd
0.53-1 (amd64-32). Both have the 2.3.1 Leap Service software installed.
I've triple-checked everything I can think of...any ideas?

On Tue, Jan 3, 2023 at 4:19 PM Christof Ressi <info at christofressi.com>
wrote:

> To be more specific, the linker error itself is most likely caused by name
> mangling differences. When you include the header file in your project, the
> class/function definitions use *your *compiler's name mangling, but the
> accompanying DLL has been built with *another *compiler, using a
> different name mangling scheme.
>
> Seems like there is also a C API:
> https://docs.ultraleap.com/tracking-api/leapc-guide.html
>
> Things are of course different on windows: you generally cannot mix&match MSVC libraries with GCC binaries (and vice versa), at least if c++ is involved.
>
> For the sake of completeness: yes, that's true for the typical case, but
> there are techniques for creating binary compatible C++ interfaces. The
> most prominent one is COM. Other examples that come to my mind are the VST3
> SDK or openvr SDK.
>
> On 03.01.2023 21:12, IOhannes m zmölnig wrote:
>
> Am 3. Jänner 2023 23:10:59 MEZ schrieb William Brent <william.brent at gmail.com> <william.brent at gmail.com>:
>
> x86_64-w64-mingw32/12.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
> src/leapmotion.o:leapmotion.cpp:(.text+0x411): undefined reference to
> `Leap::Frame::timestamp() const'
>
> C++ is a fantastic language.
> Unfortunately it is not really standardised on the binary level, which basically means that you might not be able to use c++ libraries compiled with one compiler/linker with binaries created by another compiler/linker.
>
> Now, clang kind of guarantees binary compatibility with g++ binaries, which pretty much covers the Linux & macOS worlds.
> Things are of course different on windows: you generally cannot mix&match MSVC libraries with GCC binaries (and vice versa), at least if c++ is involved.
>
> Proprietary SDKs often provide MSVC libraries.
>
> So if possible, try to use a C-library instead of a C++-library on windows.
>
>
> mfg.sfg.jfd
> IOhannes
>
>
> _______________________________________________
> Pd-dev mailing listPd-dev at lists.iem.athttps://lists.puredata.info/listinfo/pd-dev
>
> _______________________________________________
> Pd-dev mailing list
> Pd-dev at lists.iem.at
> https://lists.puredata.info/listinfo/pd-dev
>


-- 
William Brent

“Great minds flock together”
Conflations: conversational idiom for the 21st century

www.conflations.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20230105/60457a6c/attachment.htm>