Package Details: osvr-core-git 0.2.r3092.g495648e4-1

Git Clone URL: https://aur.archlinux.org/osvr-core-git.git (read-only, click to copy)
Package Base: osvr-core-git
Description: The core libraries, applications, and plugins of the OSVR software platform.
Upstream URL: https://github.com/OSVR/OSVR-Core
Submitter: haagch
Maintainer: None
Last Packager: haagch
Votes: 13
Popularity: 0.000000
First Submitted: 2015-03-27 23:09 (UTC)
Last Updated: 2022-03-13 22:46 (UTC)

Latest Comments

« First ‹ Previous 1 2 3 4 5 6 Next › Last »

godbyk commented on 2016-09-01 17:01 (UTC)

@underdog VRPN was recently updated to correct for this (see <https://github.com/vrpn/vrpn/commit/308839e5b7706e8579aae59e0160d2c45b9c75a3>.) The VRPN submodule in the OSVR-Core repository may not be updated yet, though.

underdoeg commented on 2016-09-01 15:35 (UTC)

I get the following error when trying to compile: aur-osvr-core-git/src/osvr-core/vendor/vrpn/vrpn_Connection.C:2540:24: error: aggregate ‘vrpn_start_server(const char*, char*, char*, const char*)::wait status’ has incomplete type and cannot be defined union wait status;

schmidtbag commented on 2016-01-18 00:00 (UTC)

Hmm seems like your change worked - it successfully installed. Thanks!

haagch commented on 2016-01-17 01:43 (UTC)

Huh, this is from CMakeError.log? To be honest I don't know cmake very well, but I'm guessing that this is some internal cmake test that is intentionally failing... Uhm... Well... The thing I had to change right now to build it is removing this version check: https://github.com/OSVR/OSVR-Core/commit/eeaf6eff8b0da57805e5c7a66f82b89479363e9e Allegedly (???) boost 1.60 may (???) break something in the ABI, but I do not understand what the problem is: https://github.com/OSVR/OSVR-Core/issues/323 Maybe I'm just too tired at 2:41 AM, but with this version check removed, osvr-server compiles and runs, so I updated the PKGBUILD. Whether it's fully functional - no idea.

schmidtbag commented on 2016-01-17 01:01 (UTC)

This fails to install for me. The weird thing is I managed to successfully install it 2 days ago, and now I can't. This here is where the first error shows up: CMakeFiles/cmTC_80860.dir/CheckSymbolExists.c.o: In function `main': CheckSymbolExists.c:(.text.startup+0x6): undefined reference to `pthread_create' collect2: error: ld returned 1 exit status CMakeFiles/cmTC_80860.dir/build.make:97: recipe for target 'cmTC_80860' failed make[1]: *** [cmTC_80860] Error 1 make[1]: Leaving directory '/tmp/yaourt-tmp-zorro/aur-osvr-core-git/src/osvr-core-build/CMakeFiles/CMakeTmp' Makefile:126: recipe for target 'cmTC_80860/fast' failed make: *** [cmTC_80860/fast] Error 2

haagch commented on 2016-01-10 00:27 (UTC)

Hm, I did update libfunctionality in the aur. I bumped pkgrel to be sure. Maybe AUR helpers try build osvr-core first... The boost fix is now in the PKGBUILD with sed, builds for me, thanks.

bwrsandman commented on 2016-01-09 18:18 (UTC)

There is an incompatibility with boost 1.60 but it's easily fixed by changing 105900 to 106000 at this line [1] I had the same problem with libfunctionality and rebuilding did fix it. Could you bump the libfunctionality's pkgver, that would force the rebuilding and users would not have to go digging for that solution. [1] https://github.com/OSVR/OSVR-Core/blob/10407fe818cb91e1d84aef8319a0382309132b5b/src/osvr/Common/IPCRingBuffer.cpp#L54

haagch commented on 2015-12-18 11:50 (UTC)

../lib64/libosvrPluginHost.so.0.6: undefined reference to `libfunc::loadPluginByName(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, void*)' Wild guess because of libfunc: Have you tried rebuilding libfunctionality first? If you already have an old build in src/ it could also help deleting src/ and pkg/ because of the recent ABI change. At least trackerviewer wouldn't build with the old src/ in place.

marcs commented on 2015-12-18 11:48 (UTC)

I have a linking error with the new version: http://pastebin.com/LKFqm4ET

feilen commented on 2015-09-04 04:39 (UTC)

Good news, they're shipping me out an OSVR HDK quite soon, so I'll have a much easier time of fixing up the OVR support on the Linux side of things, as well as the dozen or so other projects I'd been planning on but couldn't really get to. The kinks in OSVR's Oculus support don't seem to be a structural problem with it, just an oversight on the Linux side of things. Since they're going to be aiming for full four-platform support with OSVR (Win, Mac, Linux and Android) and Android and Linux support are heavily tied together, it's almost certainly going to have a much better support track record moving forward. Come to think of it, once I have a headset, I might start running a repository for all the working VR software. It looks like I'll have to work out how to bundle software into .deb's soon anyway, so that's an easy side-step.