Linuxtrack lib not loading

[calebaden]

I am trying to use Linuxtrack for Star Citizen using Lutris and it's umu integration. Linuxtrack works fine when using my systems wine 9.8, wine GE 8-26 and even GE-Proton9-5 (when not run through umu). This applies to running through Lutris and through the terminal both. When using UMU-Proton-9.0-beta16-2 or GE-Proton9-5 through Lutris or using umu-run in the terminal Linuxtrack does not start. If I try to run the Tester64.exe for Linuxtrack, the gui will load and open but I cannot start the actual headtracking.

Based on the Linuxtrack logs, the necessary library is not being loaded.

Successful run without umu: Trying to load '/usr/local/bin/..//Frameworks/liblinuxtrack.0.dylib'... Not found. Trying to load '/usr/local/bin/..//lib/linuxtrack/liblinuxtrack.so.0'... Loaded OK.

Unsuccessful run with umu: Trying to load '/usr/local/bin/..//Frameworks/liblinuxtrack.0.dylib'... Not found. Trying to load '/usr/local/bin/..//lib/linuxtrack/liblinuxtrack.so.0'... Not found. Trying to load '/usr/local/bin/..//lib32/linuxtrack/liblinuxtrack32.so.0'... Not found. Trying to load '/usr/local/bin/..//lib/i386-linux-gnu/linuxtrack/liblinuxtrack.so.0'... Not found. Trying to load '/usr/local/bin/..//lib/i386-linux-gnu/linuxtrack/liblinuxtrack32.so.0'... Not found. Trying to load '/usr/local/bin/..//lib/x86_64-linux-gnu/linuxtrack/liblinuxtrack.so.0'... Not found. Trying to load '/usr/local/bin/..//lib/liblinuxtrack.so.0'... Not found. Trying to load '/usr/local/bin/..//lib32/liblinuxtrack.so.0'... Not found. Trying to load '/usr/local/bin/..//lib32/liblinuxtrack32.so.0'... Not found. Trying to load '/usr/local/bin/..//lib/i386-linux-gnu/liblinuxtrack.so.0'... Not found. Trying to load '/usr/local/bin/..//lib/x86_64-linux-gnu/liblinuxtrack.so.0'... Not found. Couldn't load liblinuxtrack, headtracking will not be available!

[loathingKernel]

How and where is linuxtrack installed in your system? I think it is safe to assume that it is installed as a system package or manually through make under /usr/local but it would be helpful to have confirmation on it.

This is due to umu-launcher running Proton inside a container. The container doesn't have access to any system libraries other than graphics drivers which makes linuxtrack.so.0 unavailable to it. This https://github.com/ValveSoftware/steam-runtime/issues/288#issuecomment-717954844 also has some more information on how it works, why /usr/local cannot be made available and where that library will appear in the container.

[calebaden]

It is installed manually through make under /usr/local. I'm not that savvy with the way that all this works, I had a read over the linked issue. Is there any workaround to make this particular use case work?

[loathingKernel]

@Pednick This seems completely unrelated to the issue described here. Please open a separate issue.

[Pednick]

@Pednick This seems completely unrelated to this issue described here. Please open a separate issue.

Ok sorry will do.

[calebaden]

I'm going to close this because it seems to be intended behaviour of the pressure-vessel and out of scope for umu. A better solution would be if the headtracking could be installed on a per game basis so that it can run within the container itself, but that seems unlikely to happen.

[R1kaB3rN]

@calebaden When you ran the game with GE-Proton9-5 and without umu, did you use the Steam client?

[calebaden]

No I was getting odd behaviour earlier on when using GE-Proton9-5 in Lutris where it wouldn't use umu, but now it seems to use umu just like UMU-Proton. I tested GE-Proton9-5 in the terminal by using the wine64 binary after this behaviour changed to confirm it worked without umu.

EDIT: I should clarify that I ran GE-Proton9-5 in Lutris both when it ran with and without umu, and also directly through the terminal with and without umu.

[loathingKernel]

I have been trying to get linuxtrack to build locally, but I have been unsuccessful in building its wine integration with my system's wine 9.8. Also, there seems to be a number of forks, I tried to build the one from this repo https://github.com/exuvo/linuxtrack

As a work-around, one thing would be to try and make install linuxtrack somewhere into your home directory, for example make DESTDIR=/home/<user>/linuxtrack install. After that you can try to set LINUXTRACK_LIBS=/home/<user>/linuxtrack/usr/local/lib/linuxtrack/liblinuxtrack.so.0:/home/<user>/linuxtrack/usr/local/lib32/linuxtrack/liblinuxtrack32.so.0 as an env variable in lutris. Of course you will need to adjust the path to the relevant "lib" directories as per the /home/<user>/linuxtrack folder structure. This should load the liblinuxtrack library but I am not sure what happens next. i.e. if other libraries are missing.

Documenting some findings in case linuxtrack was to be considered for inclusion with custom Proton/SteamLinuxRuntime (Maybe in the form of a proton addon?)

• The error messages in your report indicates that linuxtrack.so.0 is loaded dynamically at runtime and that it searches a few predefined locations. These search locations are not compatible with Proton, so we would need to use LINUXTRACK_LIBS variable to set them (for example inside the container LINUXTRACK_LIBS="<proton_path>/files/usr/lib64/linuxtrack/liblinuxtrack.so.0:<proton_path>/files/usr/lib/linuxtrack/linuxtrack32.so.0").
• Configuring library paths correctly at compile-time for Proton should still not be enough for automatic discovery due to lib64 missing from the predefined locations (on top of Proton's LD_LIBRARY_PATH shenanigans). They could be patched if required.
• Linuxtrack wine plugin itself needs wine to build, so the more convenient place to build it is Proton.
• Linuxtrack needs opencv2 and mxml to build. It links to mxml only as far as I can see. This would probably mean that it would need a custom SLR to be built as part of Proton.
• Linuxtrack uses Qt4/Qt5 for its GUI applications depending on the fork used, maybe they can be skipped from the build.

[calebaden]

Definitely a lot to unpack here thanks for taking such a thorough look, I'll see if I can make something work. Linuxtrack is a pain to build at the moment, I used the same fork you mentioned, built with wine 8.21 and I was missing 'qt5-tools' package.

[calebaden]

Your suggestion of using make DESTDIR=/home/<user>/linuxtrack install allows the libraries to be loaded in the container which is great!.. But, my TrackIR device (what I use linuxtrack for) doesn't have permission to run with this setup even with the udev rules applied.

I have had the same error before when using the precompiled package of linuxtrack, I installed it in /opt/linuxtrack but it wanted to be installed in /opt/linuxtrack-0.99.18 and then symlink /opt/linuxtrack. Which makes me think that there's some sort of hard coded directory.

[loathingKernel]

Going by the message, on the host side you should be able to fix this by copying /home/<user>/linuxtrack/usr/local/share/linuxtrack/99-TIR.rules to /etc/udev/rules.d and triggering a rule reload udevadm control --reload-rules && udevadm trigger, or simply rebooting. If that doesn't work, maybe the container doesn't allow access to the device for some reason. @R1kaB3rN do you think this could be the case?

I skimmed for a hard-coded path for udev rules but couldn't find anything.

[calebaden]

Yeah I have the 99-TIR.rules applied and I know it works because it will run correctly when I install linuxtrack under /usr/local. When I say hardcoded path I'm referring to the path of the install directory, since I got this error previously when installing in /opt/linuxtrack but renaming to /opt/linuxtrack-0.99.18 fixed it. That's just my best guess though, based on the behaviour I'm seeing.

[R1kaB3rN]

Going by the message, on the host side you should be able to fix this by copying /home/<user>/linuxtrack/usr/local/share/linuxtrack/99-TIR.rules to /etc/udev/rules.d and triggering a rule reload udevadm control --reload-rules && udevadm trigger, or simply rebooting. If that doesn't work, maybe the container doesn't allow access to the device for some reason. @R1kaB3rN do you think this could be the case?

I skimmed for a hard-coded path for udev rules but couldn't find anything.

No, I do not think this is the case.

@calebaden For this to work with Proton, I believe that library will need to be properly included in the runtime platform. Also, do you mind adding the game as a non-steam game in the Steam client and running it? That'd be helpful because if you can confirm that it works there, then that means this is a bug and I can try to make a patch to address it.

[calebaden]

I have tried running as a non-steam game which has the same issues as umu, but the thing is that these issues are no longer relevant to the pressure-vessel container. I can close this issue as resolved since the liblinuxtrack.so.0 is being loaded within the container successfully.

My current issue is that linuxtrack simply does not function if not installed under /usr/local as it cannot find the other libraries. Using LD_LIBRARY_PATH does not work, using LD_PRELOAD tells me that ERROR: ld.so: object '/home/caleb/linuxtrack/usr/local/lib/linuxtrack/libltr.so.0' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS64): ignored.

[calebaden]

I have resolved all my issues by building with these commands;

./configure --prefix=$HOME/linuxtrack make install

The app runs within the container and is able to load the necessary libraries at runtime without the use of any environment variables. Hallelujah. I appreciate the help!