When trying to open the Gear City video settings editor in Steam, it appears that nothing happens. I am on Gentoo Linux using LXDE/Openbox with picom as a compositor, using a triple-monitor setup of 1280x1024, 2560x2880, and 1280x1024, with the primary monitor currently being set as the first one for better compatibility (and the secondary monitor being one of my bigger interests in using the video settings editor; I want to be able to view the big reports in some comfortable resolution like 2560x2048 or maybe 2558x2046 to account for window borders). I do not currently have a log as it is a bit of a pain to get those from Steam, but can provide them if necessary, especially if I can find a better way to get the logs than to launch re-launch Steam from a terminal. Has anyone else encountered this issue?
I have some logs now:
Code:
/bin/sh\0-c\0/home/happysmash27/.local/share/Steam/ubuntu12_32/reaper SteamLaunch AppId=285110 -- /home/happysmash27/.local/share/Steam/ubuntu12_32/steam-launch-wrapper -- '/mnt/MEGA/SteamLibrary/steamapps/common/GearCity/./ModTools/launchVS.sh'\0
Game process added : AppID 285110 "/home/happysmash27/.local/share/Steam/ubuntu12_32/reaper SteamLaunch AppId=285110 -- /home/happysmash27/.local/share/Steam/ubuntu12_32/steam-launch-wrapper -- '/mnt/MEGA/SteamLibrary/steamapps/common/GearCity/./ModTools/launchVS.sh'", ProcID 12272, IP 0.0.0.0:0
chdir /mnt/MEGA/SteamLibrary/steamapps/common/GearCity/./ModTools
ERROR: ld.so: object '/home/happysmash27/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored.
ERROR: ld.so: object '/home/happysmash27/.local/share/Steam/ubuntu12_64/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS64): ignored.
ERROR: ld.so: object '/home/happysmash27/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored.
ERROR: ld.so: object '/home/happysmash27/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored.
ERROR: ld.so: object '/home/happysmash27/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored.
./VideoSettings: error while loading shared libraries: libsystemd.so.0: cannot open shared object file: No such file or directory
Game process removed: AppID 285110 "/home/happysmash27/.local/share/Steam/ubuntu12_32/reaper SteamLaunch AppId=285110 -- /home/happysmash27/.local/share/Steam/ubuntu12_32/steam-launch-wrapper -- '/mnt/MEGA/SteamLibrary/steamapps/common/GearCity/./ModTools/launchVS.sh'", ProcID 12272
Uploaded AppInterfaceStats to Steam
GameAction [AppID 285110, ActionID 1] : LaunchApp changed task to WaitingGameWindow with ""
GameAction [AppID 285110, ActionID 1] : LaunchApp changed task to Completed with ""
Why in the world does a video settings editor depend on a system service init system??
While waiting for a response, I wonder if there is some way to get around this, maybe making a dummy library. Or better yet, some way to edit the settings directly, bypassing the settings editor. I am not sure where any of the settings would be stored though.
Update:
I wonder if it's even the video settings editor directly causing this issue. Running LDD on it, I notice these lines:
Code:
libQt5Core.so.5:
libsystemd.so.0 (LIBSYSTEMD_209) => not found
And running objdump, there is nothing related to systemd.
Which makes me wonder, is it just QT using this in a way that for some reason does not cause this crash in any other program I know of??
Update again!
Trying to find the library, I realised it might also be an embedded library and that would be why it is not compatible with my system. And indeed, if I look at the GearCity folder, there is in fact a libQt5Gui.so.5 that relies on systemd!
Unfortunately, moving that from libQt5Core.so.5 to libQt5Core.so.5.disabled, I get another error message when running ./launchVS.sh:
Code:
Cannot mix incompatible Qt library (5.15.2) with this library (5.15.8)
./launchVS.sh: linio 1ª: 25622 Abortita LD_LIBRARY_PATH=../ ./VideoSettings
And even if I launch VideoSetings directly without the LD_LIBRARY_PATH in the script, it still gives the same issue.
So, I think I know what the problem is. Now the question is, how in the world to make this compatible…
Update 4:
Running LDD on Videosettings, I realise that it is still pulling the QT libraries from the Gear City folder:
Code:
libQt5Widgets.so.5 => /mnt/MEGA/SteamLibrary/steamapps/common/GearCity/ModTools/./../libQt5Widgets.so.5 (0x00007f5572912000)
libQt5Gui.so.5 => /mnt/MEGA/SteamLibrary/steamapps/common/GearCity/ModTools/./../libQt5Gui.so.5 (0x00007f55721f9000)
libQt5Xml.so.5 => /mnt/MEGA/SteamLibrary/steamapps/common/GearCity/ModTools/./../libQt5Xml.so.5 (0x00007f55721ae000)
libQt5Core.so.5 => /usr/lib64/libQt5Core.so.5 (0x00007f5571c07000)
However, even if I move those to .disabled versions too, it still fails with the same error message, making me suspect that I may have to, somehow, manually build an entirely separate build of an older version of QT at an older version than Portage currently would let me install, or maybe try to see if the Steam runtime has something (it doesn't seem to). The only other non-system library it's pulling in at this point is libsteam_api.so.
Sadly, it's the nature of the beast when it comes to packaging Linux binaries, especially since systemd has infected just about everything. (And Steam runtime is stuck on Ubuntu 14 and 18 12.) That said, it shouldn't be linking anything systemd related. (And I believe the steam runtime has systemd libs in even if it did.)
You should be able to take QT 5.15 so files on your system and replace the ones shipped with the game. There should only be three .so files. Replace the ones included in the game with what you have on your system. I'm only in the office around midnight on weekdays. But I will check what files those are when I get in. (5 hours or so.)
Have you ran the binary file directly? ./VideoSettingsEditor or whatever the binary name is?
There are six files you'll need to replace with whatever is on your system:
libQt5Core.so.5 libQt5DBus.so.5 libQt5Gui.so.5 libQt5Widgets.so.5 libQt5XcbQpa.so.5 libQt5Xml.so.5
Any QT5.15 minor versions should work so long as you replace them all in the GearCity folder. Be sure they're the actual lib files and not symlinks to the files.
Alternatively, you can switch to an older build of the game, copy the binary files for that, then switch back to the modern version of the game, and then use those binary files. They will use the QT4 shipped with the game.
The final option would be to compile the tools yourself. They're open source.
https://github.com/gearcity/GearCity_Vid...ingsEditor
I believe I'm using the dev packages that come with Mageia and I'm not building from QT from source. I'll double check if that's the case next time I get around to building the mod tools. A quick look on pkg.org, and I can't find any other distros that I can check to see if they're automatically linking systemd now. (I built the previous 32-bit mod tools with Slackware, but had to include a whole bunch of libraries.) (Which reminds me, perhaps the gog build would have done something...)
All of that said, the settings files are text files that you can edit. GearCity/GearCity/Settings/ folder, you'll find "LinuxVideoConfig.xml." That's just something to tide you over.
Although this is likely to cause cascading missing files, you could also try slapping systemd.so.0 in the folder with the QT.so files.
I'm showing these depends, most of which you should have:
linux-vdso.so.1 (0x00007ffcdb58e000)
librt.so.1 => /lib64/librt.so.1 (0x00007f556f85b000)
liblzma.so.5 => /lib64/liblzma.so.5 (0x00007f556f82a000)
libzstd.so.1 => /lib64/libzstd.so.1 (0x00007f556f74f000)
liblz4.so.1 => /lib64/liblz4.so.1 (0x00007f556f72c000)
libcap.so.2 => /lib64/libcap.so.2 (0x00007f556f722000)
libgcrypt.so.20 => /lib64/libgcrypt.so.20 (0x00007f556f5ff000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f556f5dd000)
libc.so.6 => /lib64/libc.so.6 (0x00007f556f413000)
/lib64/ld-linux-x86-64.so.2 (0x00007f556f941000)
libgpg-error.so.0 => /lib64/libgpg-error.so.0 (0x00007f556f3ed000)
(04-05-2023, 06:33 PM)Eric.B Wrote: [ -> ]You should be able to take QT 5.15 so files on your system and replace the ones shipped with the game. There should only be three .so files. Replace the ones included in the game with what you have on your system. I'm only in the office around midnight on weekdays. But I will check what files those are when I get in. (5 hours or so.)
Have you ran the binary file directly? ./VideoSettingsEditor or whatever the binary name is?
When moving the (renaming) libraries to .disabled versions, the ./VideoSettingsEditor already uses the system libraries, if I understand correctly, and as mentioned in the second update I already tried running it directly (this does the same thing but writes `zsh: IOT instruction ./VideoSettings` instead of `./launchVS.sh: linio 1ª: 30214 Abortita LD_LIBRARY_PATH=../ ./VideoSettings`). The problem is, if I'm reading the error correctly, that ./VideoSettingsEditor seems to depend on QT 1.15.2, while I have 1.15.8 which is apparently incompatible. Meaning, I would presumably have to manually recompile an entirely separate version of QT with the -no-systemd flag enabled (which I have not done yet; got sidetracked by some other things while trying to figure out which module set I should enable).
...
So, I decided while writing this post to try moving the actual .so files to the GearCity folder just in case I was wrong that moving/renaming things to .disabled versions caused the system libraries to be used. It appears I was not actually wrong, BUT, in the process of starting to do this, I moved the remaining QT libraries to .disabled versions, and despite those libraries not having shown up in ldd, doing this DOES actually make it work!
So, now I have a solid, easy workaround that does not require recompiling the entire QT libraries: Just disable all the built in ones – ALL of them, rather than just the ones that looked like they were being used.
It is extremely good to know that the video settings editor and mod tools are open source. Had this not worked, that would have definitely been my first choice in fixing this, as compiling a small dependency is MUCH faster and easier than compiling a huge monolith like QT.
I also notice a minor bug in the settings editor: It will not let me put a resolution larger than 1280x1024, even if I set the monitor index to 1. Knowing it is open source, it would likely not be hard to fix that at all! (Probably easier to just change my primary monitor for now though).
Awww, I was just about to complete my Gentoo VM install to see if I could duplicate the issue and get you a quick workaround. Great to hear you fixed it! (I can go back to working on the emissions bounty for the FBS.)
For GearCity 'Classic' v2.0.0.9, I'll be creating a launcher program to handle in-game news, launching the FBS, Mod-Tools, Video Settings Editor, etc. (
Bounty #1) With that I will build QT5 from scratch, as it's probably my distro that tainted the QT5-Core file with systemd depends. Normally, I do my building in Slackware, since they're extremely vanilla with their packages. However, I did an unplanned port from QT4 to QT5 because of many HiDPI complaints with QT4, and I took the half-assed measure of just using the qt5-dev package included with Mageia.
So this will be fixed when I do that bounty for the GearCity "Classic" update.
Quote:I also notice a minor bug in the settings editor: It will not let me put a resolution larger than 1280x1024, even if I set the monitor index to 1. Knowing it is open source, it would likely not be hard to fix that at all! (Probably easier to just change my primary monitor for now though).
Interesting, it seems to work for me on this computer. Setting the monitor to 1 does open the game on the correct monitor, right? You should be able to enter a custom resolution, or alternatively, set one in the .xml file.
(If you take a gander at the code, forgive its messiness. Sadly, being a solo dev in game dev, I often have to be overly hasty, and that leads to sloppy code.)