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

William Brent william.brent at gmail.com
Thu Jan 5 20:50:15 CET 2023


Finally, success! Thanks very much Christof. I'm guessing that the
additional dependencies were available on my compiling machine because I
have Visual Studio installed on that one, but not the other. So...just one
last question (hopefully): what's the best practice for packaging an
external like this? The dependencies are:

   - kernel32.dll
   - Leap.dll
   - msvcp140d.dll
   - pd.dll
   - ucrtbased.dll
   - vcruntime140d.dll
   - vcruntime140_1d.dll

Some of these can be expected to be available on any windows 10 machine
with Pd installed, but what about the others? In the case of my test
machine without visual studio, I needed to include everything except
kernel32.dll and pd.dll. Is it too ugly to just include all of these .dlls
in the deken package for windows? Would a .bat script be a good idea so
that all of these could be copied to Windows/System32?

On Thu, Jan 5, 2023 at 9:04 AM Christof Ressi <info at christofressi.com>
wrote:

> Hey,
>
> this can also happen when an auxiliary library cannot be found. You can
> check missing dependencies with the Dependencies program (modern successor
> to Dependency Walker): https://github.com/lucasg/Dependencies
>
> Christof
> On 05.01.2023 19:48, William Brent wrote:
>
> 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
>
> _______________________________________________
> 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/de033d55/attachment.htm>


More information about the Pd-dev mailing list