Linux dynamic build should have a build option to include dynamic libraries.

[Redhawk18]

Hey everyone this is my first time hearing about this framework, and it seems really cool. I wanted to raise an issue because often times when games are put on steam the end user loses a lot of ability to deal with technical issues besides installing a runtime or something required for the game. For me I use the distro nixos which does not play well with appimages, There are tools that allow appimages to run but they are not generic binaries you can distribute through steam. I understand something like a static binary would be impossible because of GPL license concerns, but it should be possible to package .so's with projects instead of just relaying on what the user has on their system. Having the dynamic object files in the games folder would also make it more stable if something on the user's system is uninstalled or something the user has choose about their system does not align with your dev system.

tldr: I'm returning Gravity Circuit on steam because the engine doesn't support proper .so support and I will never buy a game made in love until this can be fixed.

[slime73]

You (or a developer of love games) can extract the appimage to make it a standalone folder full of .so files with an executable that can be run. Does that answer the request? I'm not totally sure I followed.

[Redhawk18]

You (or a developer of love games) can extract the appimage to make it a standalone folder full of .so files with an executable that can be run. Does that answer the request? I'm not totally sure I followed.

I'm just an end user I was told by lead dev of Gravity Circuit that the engine basically relies on system dynamic objects? So your saying this would be easy for a dev to do? I could fix this if I had the source of the game and the engine, but it's all locked be hide Steam's drm and other restrictions.

[slime73]

Yes, it's described here - it doesn't rely on system packages aside from some minimum requirements for how old glibc can be: https://love2d.org/wiki/Game_Distribution#Official_AppImage

[Redhawk18]

Yes, it's described here - it doesn't rely on system packages aside from some minimum requirements for how old glibc can be: https://love2d.org/wiki/Game_Distribution#Official_AppImage

Hm this might be an issue with how steam sandboxes applications. log from steam

chdir "/mnt/games/SteamLibrary/steamapps/common/Gravity Circuit"
ERROR: ld.so: object '/home/redhawk/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored.
ERROR: ld.so: object '/home/redhawk/.local/share/Steam/ubuntu12_64/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS64): ignored.
ERROR: ld.so: object '/home/redhawk/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored.
Adding process 9088 for gameID 858710
ERROR: ld.so: object '/home/redhawk/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored.
dlopen(): error loading libfuse.so.2

AppImages require FUSE to run. 
You might still be able to extract the contents of this AppImage 
if you run it with the --appimage-extract option. 
See https://github.com/AppImage/AppImageKit/wiki/FUSE 
for more information
Uploaded AppInterfaceStats to Steam
Removing process 9088 for gameID 858710

log from running the appimage as a normal binary

❯ ./GravityCircuit.AppImage 
[BUILD] Not forcing demo mode.
[ALSOFT] (EE) Failed to set real-time priority for thread: Operation not permitted (1)
[ALSOFT] (EE) Failed to set real-time priority for thread: Operation not permitted (1)
Error: Could not initialize SDL video subsystem (No available video device)
stack traceback:
        [love "boot.lua"]:345: in function <[love "boot.lua"]:341>
        [C]: at 0x7fbd9286f420
        [C]: in function 'require'
        [love "boot.lua"]:251: in function <[love "boot.lua"]:126>
        [C]: in function 'xpcall'
        [love "boot.lua"]:355: in function <[love "boot.lua"]:348>
        [C]: in function 'xpcall'

While the 2nd doesn't work it shows that libfuse is found which it doesn't on steam. This is likely the core issue I'm having, maybe including libfuse as a dep if you are building an appimage would solve it?

[slime73]

Neither of those is running the extracted folder though, which is what I was describing above.

For your second example where there's no compatible windowing backend for SDL to use, love 11 requires X11 support (via actual X11 or XWayland) on Linux. I guess it can't find that?

[Redhawk18]

Neither of those is running the extracted folder though, which is what I was describing above.

For your second example where there's no compatible windowing backend for SDL to use, love 11 requires X11 support (via actual X11 or XWayland) on Linux. I guess it can't find that?

I have that setup in nix-ld my linker but it also confuses me.

[Redhawk18]

I'm going to check with the linker project, it's likely that.

[MikuAuahDark]

"Could not initialize SDL video subsystem" may indicate that you're missing X11 in your system. LOVE 11 AppImage is not compiled with Wayland support due to it targeting quite old distro.

Assume you have permission from the game developer, run thegame.AppImage --appimage-extract. It will create squashfs-root folder. In that folder, simply run AppRun. If it still doesn't work, try removing libSDL2-2.0.so from the lib folder and try again too.

[Redhawk18]

"Could not initialize SDL video subsystem" may indicate that you're missing X11 in your system. LOVE 11 AppImage is not compiled with Wayland support due to it targeting quite old distro.

Assume you have permission from the game developer, run thegame.AppImage --appimage-extract. It will create squashfs-root folder. In that folder, simply run AppRun. If it still doesn't work, try removing libSDL2-2.0.so from the lib folder and try again too.

I'll try this, I got confused with the docs and went into the bin folder and did game < love and it didn't work.

[Redhawk18]

common/Gravity Circuit/squashfs-root 
❯ ./AppRun 
[BUILD] Not forcing demo mode.
[ALSOFT] (WW) Failed to load libjack.so.0
[ALSOFT] (WW) Failed to initialize backend "jack"
[ALSOFT] (EE) Failed to set real-time priority for thread: Operation not permitted (1)
[ALSOFT] (EE) Failed to set real-time priority for thread: Operation not permitted (1)
[S_API] SteamAPI_Init(): Loaded '/home/redhawk/.local/share/Steam/linux64/steamclient.so' OK.
[S_API FAIL] SteamAPI_Init() failed; no appID found.
Either launch the game from Steam, or put the file steam_appid.txt containing the correct appID in your game folder.
Couldn't connect to steam...
Do you have Steam turned on?
If not running from steam, do you have a correct steam_appid.txt file?
[S_API FAIL] Tried to access Steam interface STEAMUSERSTATS_INTERFACE_VERSION012 before SteamAPI_Init succeeded.
Segmentation fault (core dumped)

So I guess this means it worked more than it did on steam. But not enough.

[MikuAuahDark]

So it runs without removing libSDL2-2.0.so from the squashfs-root/lib folder?

[Redhawk18]

So it runs without removing libSDL2-2.0.so from the squashfs-root/lib folder?

Maybe? It depends, I assume the engine will init sdl and then call the users code which is libsteam here.

[Redhawk18]

This is steam's fault

[Redhawk18]

One last question, does using love SuperGame.love create a effectively the same binary as appimages do? @MikuAuahDark @slime73

[MikuAuahDark]

Not entirely equivalent. Yes it will be same love binary, but it's not fused as far as the game aware.

[slime73]

If you're running a game as a command-line parameter to love, you can pass in --fused to make the game behave as if it is fused.

That being said, the forums or discord server or subreddit are better places for questions/answers about usage, this issue tracker is meant for love's source code.