Hello all,
I'm finishing up work on new [leapmotion] and [ultraleap] externals and trying to make them available for all compatible platforms (I'll skip the rundown of which hardware and SDKs work on which platforms here unless it's helpful).
I've got everything working except the [leapmotion] external for Windows. I'm using pd-lib-builder and MSYS2 MinGW 64-bit and am able to compile successfully, but linking to the 64-bit Leap library fails with a stream of "undefined reference to" messages. I'm positive that gcc can find the Leap.h header and the Leap.lib/Leap.dll libraries in my Leap SDK 2.3.1 directory, and have done a nearly identical build process for the [ultraleap] using the LeapC SDK 5.7.2 where linking succeeds and everything works fine.
I'd be very grateful if anyone could shed some light on what I'm doing wrong here. There's no need for any Leap hardware for building, you just need to clone my [leapmotion] repo here: https://github.com/wbrent/leapmotion and download Leap SDK version 2.3.1 for Windows here: https://developer.leapmotion.com/releases
From there it's just a matter of editing the Makefile to specify your Leap
SDK directory location and attempting a "make" in MSYS2. I'm using Windows 10 Home, Pd 0.53-1 (amd64-32), and pd-lib-builder version 0.6.0. Below is a truncated version of what I get in my attempts.
Any suggestions or further questions are welcome, thanks! William
++++ info: using Makefile.pdlibbuilder version 0.6.0 ++++ info: using Pd API C:\Program Files/Pd/src/m_pd.h ++++ info: making target all in lib leapmotion ++++ info: making src/leapmotion.o in lib leapmotion g++ -DPD -I "C:\Program Files/Pd/src" -DMSW -DNT -DPD_LONGINTTYPE=__int64 -fcheck-new -Iinclude -I/c/msys64/dev/LeapDeveloperKit_2.3.1+31549_win/LeapSDK/include -Wall -Wextra -Wshadow -Winline -Wstrict-aliasing -O3 -ffast-math -funroll-loops -fomit-frame-pointer -march=core2 -msse -msse2 -msse3 -mfpmath=sse -o src/leapmotion.o -c src/leapmotion.cpp . . . ++++ info: making src/Dispatcher.o in lib leapmotion g++ -DPD -I "C:\Program Files/Pd/src" -DMSW -DNT -DPD_LONGINTTYPE=__int64 -fcheck-new -Iinclude -I/c/msys64/dev/LeapDeveloperKit_2.3.1+31549_win/LeapSDK/include -Wall -Wextra -Wshadow -Winline -Wstrict-aliasing -O3 -ffast-math -funroll-loops -fomit-frame-pointer -march=core2 -msse -msse2 -msse3 -mfpmath=sse -o src/Dispatcher.o -c src/Dispatcher.cpp . . . ++++ info: making src/LeapMotionObj.o in lib leapmotion g++ -DPD -I "C:\Program Files/Pd/src" -DMSW -DNT -DPD_LONGINTTYPE=__int64 -fcheck-new -Iinclude -I/c/msys64/dev/LeapDeveloperKit_2.3.1+31549_win/LeapSDK/include -Wall -Wextra -Wshadow -Winline -Wstrict-aliasing -O3 -ffast-math -funroll-loops -fomit-frame-pointer -march=core2 -msse -msse2 -msse3 -mfpmath=sse -o src/LeapMotionObj.o -c src/LeapMotionObj.cpp . . . ++++ info: linking objects in leapmotion.dll for lib leapmotion g++ -static-libgcc -static-libstdc++ -shared -Wl,--enable-auto-import "C:\Program Files/Pd/bin/pd.dll" -L/c/msys64/dev/LeapDeveloperKit_2.3.1+31549_win/LeapSDK/lib/x64 -o leapmotion.dll src/leapmotion.o src/Dispatcher.o src/LeapMotionObj.o -lLeap C:/msys64/mingw64/bin/../lib/gcc/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() cons t' C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/12.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: src/leapmotion.o:leapmotion.cpp:(.text+0x45d): undefined reference to `Leap::Frame::Frame()' . . . C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/12.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: src/LeapMotionObj.o:LeapMotionObj.:(.text+0xf8): undefined reference to `Leap::Interface::~Interface ()' collect2.exe: error: ld returned 1 exit status make: *** [pd-lib-builder//Makefile.pdlibbuilder:885: leapmotion.dll] Error 1
Am 3. Jänner 2023 23:10:59 MEZ schrieb William Brent william.brent@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
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 Brentwilliam.brent@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 list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Thanks for the extra explanation, that's helpful info. About the C API: yes I'm already using that one successfully on Windows to build my [ultraleap] external. And that API even works for both the Leap Motion and Ultraleap hardware, which is nice. Unfortunately, that API (LeapC) no longer supports gesture and tool tracking. That's why I'm bothering with the old C++ API - so that Windows users with a Leap Motion Controller can track gestures/tools in addition to hands.
On Tue, Jan 3, 2023 at 4:19 PM Christof Ressi info@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@gmail.com william.brent@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@lists.iem.athttps://lists.puredata.info/listinfo/pd-dev
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
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@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@gmail.com william.brent@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@lists.iem.athttps://lists.puredata.info/listinfo/pd-dev
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
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@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.htmlThings 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@gmail.com> <mailto:william.brent@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 list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev_______________________________________________ Pd-dev mailing list Pd-dev@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 http://www.conflations.com
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
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@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@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@gmail.com william.brent@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@lists.iem.athttps://lists.puredata.info/listinfo/pd-dev
Pd-dev mailing list Pd-dev@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@lists.iem.athttps://lists.puredata.info/listinfo/pd-dev
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
so...just one last question (hopefully): what's the best practice for packaging an external like this? The dependencies are:
kernel32.dll is always present and must not be distributed.
msvcp140d.dll, ucrtbase.dll and vcruntime140*.dll are Microsoft C runtime libraries.
Can you send me the binaries, so I can quickly have a look myself?
Would a .bat script be a good idea so that all of these could be copied to Windows/System32?
Anything, but not this! The days of copying stuff into System32 are - fortunately - long gone :-)
Christof
If you want to learn the ugly details:
https://learn.microsoft.com/en-us/cpp/windows/deploying-native-desktop-appli...
On 05.01.2023 16:20, Christof Ressi wrote:
so...just one last question (hopefully): what's the best practice for packaging an external like this? The dependencies are:
kernel32.dll is always present and must not be distributed.
msvcp140d.dll, ucrtbase.dll and vcruntime140*.dll are Microsoft C runtime libraries.
Can you send me the binaries, so I can quickly have a look myself?
Would a .bat script be a good idea so that all of these could be copied to Windows/System32?
Anything, but not this! The days of copying stuff into System32 are - fortunately - long gone :-)
Christof
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Thanks IOhannes, this is helpful and it explains why I was able to link to the newest Leap library on Windows for the ultraleap external - that one is in straight C.
That said, would it be worth my time to try and set up a Visual Studio project and build against the old C++ library there? I only have experience using VS with JUCE-generated projects so it would be a bit of a slog for me to try and set things up from a blank slate, but I'd be game if there's hope it'll work. I'm just trying to get this accessible to as many students as possible, and the old library offers tool and gesture tracking, which Leap has dropped in the new version.
On Tue, Jan 3, 2023 at 3:13 PM IOhannes m zmölnig zmoelnig@iem.at wrote:
Am 3. Jänner 2023 23:10:59 MEZ schrieb William Brent < william.brent@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 list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
That said, would it be worth my time to try and set up a Visual Studio project and build against the old C++ library there?
If you use CMake, you only have to specify the appropriate Visual Studio generator. That's it. You build your project with
cmake --build .
and it will automatically use the MSVC++ compiler. No need to open Visual Studio at all. (Of course, you have to install it.)
---
Another thing you could do is write your own C wrapper library around the original Leap C++ library, build it with MSVC++ and then use that for your Pd external.
Christof
On 04.01.2023 02:31, William Brent wrote:
Thanks IOhannes, this is helpful and it explains why I was able to link to the newest Leap library on Windows for the ultraleap external - that one is in straight C.
That said, would it be worth my time to try and set up a Visual Studio project and build against the old C++ library there? I only have experience using VS with JUCE-generated projects so it would be a bit of a slog for me to try and set things up from a blank slate, but I'd be game if there's hope it'll work. I'm just trying to get this accessible to as many students as possible, and the old library offers tool and gesture tracking, which Leap has dropped in the new version.
On Tue, Jan 3, 2023 at 3:13 PM IOhannes m zmölnig zmoelnig@iem.at wrote:
Am 3. Jänner 2023 23:10:59 MEZ schrieb William Brent <william.brent@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 list Pd-dev@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 http://www.conflations.com
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Great tips, thanks to you both!
On Tue, Jan 3, 2023 at 3:45 PM Christof Ressi info@christofressi.com wrote:
That said, would it be worth my time to try and set up a Visual Studio project and build against the old C++ library there?
If you use CMake, you only have to specify the appropriate Visual Studio generator. That's it. You build your project with
cmake --build .
and it will automatically use the MSVC++ compiler. No need to open Visual Studio at all. (Of course, you have to install it.)
Another thing you could do is write your own C wrapper library around the original Leap C++ library, build it with MSVC++ and then use that for your Pd external.
Christof On 04.01.2023 02:31, William Brent wrote:
Thanks IOhannes, this is helpful and it explains why I was able to link to the newest Leap library on Windows for the ultraleap external - that one is in straight C.
That said, would it be worth my time to try and set up a Visual Studio project and build against the old C++ library there? I only have experience using VS with JUCE-generated projects so it would be a bit of a slog for me to try and set things up from a blank slate, but I'd be game if there's hope it'll work. I'm just trying to get this accessible to as many students as possible, and the old library offers tool and gesture tracking, which Leap has dropped in the new version.
On Tue, Jan 3, 2023 at 3:13 PM IOhannes m zmölnig zmoelnig@iem.at wrote:
Am 3. Jänner 2023 23:10:59 MEZ schrieb William Brent < william.brent@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 list Pd-dev@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@lists.iem.athttps://lists.puredata.info/listinfo/pd-dev
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
-
Christof Ressi -
IOhannes m zmölnig -
William Brent