Issues with Love2D - Githubissues

ghost commented 6 years ago

I'm working on a game that I would like to package using AppImage but I am having a couple problems:

The libraries seemingly aren't being found as the appimage errors out with an error about missing liblove on systems without love2d installed.
The game .love file isn't being sourced from the appimage

I've been trying to build this image from Arch linux using the latest appimagetool and the following structure. If needed I can post the file contents as well...

$ tree Reboot.AppDir/
Reboot.AppDir/
├── AppRun
├── reboot.desktop
├── reboot.love
├── reboot.png
└── usr
    ├── bin
    │   └── love
    ├── lib
    │   ├── libbz2.so.1.0
    │   ├── libc.so.6
    │   ├── libdl.so.2
    │   ├── libfreetype.so.6
    │   ├── libgcc_s.so.1
    │   ├── libglib-2.0.so.0
    │   ├── libgraphite2.so.3
    │   ├── libharfbuzz.so.0
    │   ├── liblove.so.0
    │   ├── libluajit-5.1.so.2
    │   ├── libmodplug.so.1
    │   ├── libmpg123.so.0
    │   ├── libm.so.6
    │   ├── libogg.so.0
    │   ├── libopenal.so.1
    │   ├── libpcre.so.1
    │   ├── libphysfs.so.1
    │   ├── libpng16.so.16
    │   ├── libpthread.so.0
    │   ├── librt.so.1
    │   ├── libSDL2-2.0.so.0
    │   ├── libstdc++.so.6
    │   ├── libtheoradec.so.1
    │   ├── libvorbisfile.so.3
    │   ├── libvorbis.so.0
    │   └── libz.so.1
    ├── lib64
    │   └── ld-linux-x86-64.so.2
    └── share
        ├── applications
        │   └── love.desktop
        ├── doc
        │   └── love -> liblove0
        ├── icons
        │   └── hicolor
        │       └── scalable
        │           └── mimetypes
        │               └── application-x-love-game.svg
        ├── man
        │   └── man6
        │       └── love.6.gz
        ├── mime
        │   └── packages
        │       └── love.xml
        └── pixmaps
            └── love.svg

16 directories, 38 files

The AppRun file is just a bash file with an echo line and /usr/bin/love reboot.love. It's worth noting that I also tried putting the reboot.love gamefile in /usr/bin/ but that seemingly changed nothing.

ghost commented 6 years ago

Also, I ran ldd /usr/bin/love to determine what libs were needed by love to run.

$ ldd /usr/bin/love
    linux-vdso.so.1 (0x00007ffc24870000)
    liblove.so.0 => /usr/lib/liblove.so.0 (0x00007f18a4b00000)
    libluajit-5.1.so.2 => /usr/lib/libluajit-5.1.so.2 (0x00007f18a488f000)
    libc.so.6 => /usr/lib/libc.so.6 (0x00007f18a44d7000)
    libSDL2-2.0.so.0 => /usr/lib/libSDL2-2.0.so.0 (0x00007f18a41cb000)
    libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0x00007f18a3f05000)
    libopenal.so.1 => /usr/lib/libopenal.so.1 (0x00007f18a3c39000)
    libz.so.1 => /usr/lib/libz.so.1 (0x00007f18a3a22000)
    libmodplug.so.1 => /usr/lib/libmodplug.so.1 (0x00007f18a3697000)
    libvorbisfile.so.3 => /usr/lib/libvorbisfile.so.3 (0x00007f18a348e000)
    libtheoradec.so.1 => /usr/lib/libtheoradec.so.1 (0x00007f18a3275000)
    libogg.so.0 => /usr/lib/libogg.so.0 (0x00007f18a306e000)
    libmpg123.so.0 => /usr/lib/libmpg123.so.0 (0x00007f18a2e0f000)
    libphysfs.so.1 => /usr/lib/libphysfs.so.1 (0x00007f18a2be2000)
    libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00007f18a285b000)
    libm.so.6 => /usr/lib/libm.so.6 (0x00007f18a250f000)
    libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x00007f18a22f8000)
    libdl.so.2 => /usr/lib/libdl.so.2 (0x00007f18a20f4000)
    /lib64/ld-linux-x86-64.so.2 => /usr/lib64/ld-linux-x86-64.so.2 (0x00007f18a4fb2000)
    libpthread.so.0 => /usr/lib/libpthread.so.0 (0x00007f18a1ed6000)
    librt.so.1 => /usr/lib/librt.so.1 (0x00007f18a1cce000)
    libbz2.so.1.0 => /usr/lib/libbz2.so.1.0 (0x00007f18a1abe000)
    libpng16.so.16 => /usr/lib/libpng16.so.16 (0x00007f18a1888000)
    libharfbuzz.so.0 => /usr/lib/libharfbuzz.so.0 (0x00007f18a15ea000)
    libvorbis.so.0 => /usr/lib/libvorbis.so.0 (0x00007f18a13bd000)
    libglib-2.0.so.0 => /usr/lib/libglib-2.0.so.0 (0x00007f18a109e000)
    libgraphite2.so.3 => /usr/lib/libgraphite2.so.3 (0x00007f18a0e72000)
    libpcre.so.1 => /usr/lib/libpcre.so.1 (0x00007f18a0bff000)

probonopd commented 6 years ago

Which method/script/tool did you use to produce the AppDir and the AppRun script?

Possibly the easiest way would be to use linuxdeployqt. It can deploy the libraries for you.

ghost commented 6 years ago

@probonopd I wrote it myself as I was unaware that it should be generated. Here is the file:

#!/bin/sh

SELF_DIR=$(dirname $(readlink -f $0))
LIBS_PATH=$SELF_DIR/usr/lib:$SELF_DIR/usr/lib64

if [ -z $LD_LIBRARY_PATH ]; then
  LD_LIBRARY_PATH=$LIBS_PATH
else
  LD_LIBRARY_PATH=$LIBS_PATH:$LD_LIBRARY_PATH
fi

export LD_LIBRARY_PATH
export PATH

exec $SELF_DIR/usr/bin/love $SELF_DIR/reboot.love

ghost commented 6 years ago

So now the appimage is working on my local development machine (has love2D installed) but produces a segfault on Arch linux (KDE) and also fails to run on Elementary OS due to some errors (I was not able to capture) related to ld-linux-x86-64.so.2 and libc.so.6. If you'd prefer, I can provide you access to the project in order to build or run the application yourself.

probonopd commented 6 years ago

Please make sure that none of the libraries on the excludelist are bundled in the AppImage. Bundling such libraries, e.g., libc.so.6, libstdc++.so.6 or libpthread.so.0, may lead to crashes. All such libraries are on the excludelist and should thus not be bundled.

While it is entirely possible to do it by hand, we generally don't recommend it: https://github.com/AppImage/AppImageKit/wiki/Creating-AppImages

Also make sure to use an older distribution such as Ubuntu 14.04 or older as the build system in order to maximize compatibility with older systems. A great way to do this is to use a service like the Open Build Service or Travis CI.

ghost commented 6 years ago

Okay thanks! I removed the libraries in the excludelist and the appimage now works on my Arch/KDE installation but is now having issues on Elementary OS (something about ZLIB missing for libpng)

Side Note: For what its worth, this process would have been much simpler if the documentation was a bit more detailed. There is a lot of info missing that I had to dig for and play around with to fix some of these issues. I would love to see a hello world example that shows the full process for new users/developers.

ghost commented 6 years ago

@probonopd so the problem I am running into is related to this error: /lib/x86_64-linux-gnu/libz.so.1: version ZLIB_1.2.9 not found (required by /tmp/.mouse_Rebooty8IEl/usr/lib/libpng16.so.16)

probonopd commented 6 years ago

Okay thanks! I removed the libraries in the excludelist and the appimage now works on my Arch/KDE installation

I hope you didn't use Arch for making the AppImage. We recommend to use the oldest still-supported LTS/Enterprise versions, e.g, Ubuntu 14.04 (trusty). Otherwise your users will not be able to run the resulting binaries (AppImage or otherwise) on distributions older than your build machine. This is covered at length in the documentation: https://github.com/AppImage/AppImageKit/wiki/Creating-AppImages#binaries-compiled-on-old-enough-base-system

So you should always build on the oldest system that your users still might be running; at this time, Ubuntu 14.04 (trusty) is the oldest still-supported (by Canonical) release and hence a good choice.

but is now having issues on Elementary OS (something about ZLIB missing for libpng) /lib/x86_64-linux-gnu/libz.so.1: version ZLIB_1.2.9 not found (required by /tmp/.mouse_Rebooty8IEl/usr/lib/libpng16.so.16)

libz = zlib is a basic system library which we assume to be present on all taget systems. However it seems like the binaries inside your AppImage require a version that is "too new" for the systems your users might be using, e.g., those on Elementary OS.

Looking at https://abi-laboratory.pro/tracker/timeline/zlib/, zlib 1.2.9 is from 2017. This is way too new. At this point, you cannot assume to be anything newer than 1.2.8 to be present on your users' systems.

Compiling on Ubuntu 14.04 (trusty) should solve this.

Side Note: For what its worth, this process would have been much simpler if the documentation was a bit more detailed.

We have heard this before and we really would like to change this, but is is hard to know what specifically is missing.

There is a lot of info missing that I had to dig for and play around with to fix some of these issues.

Can you give concrete examples please?

I would love to see a hello world example that shows the full process for new users/developers.

https://github.com/probonopd/linuxdeployqt#using-linuxdeployqt-with-travis-ci

ghost commented 6 years ago

Okay.. I'll give this compilation on Ubuntu a shot, however I wonder if it wouldn't work just to include the version of zlib required by my application? Also, I regards to documentation, I found that info about the AppRun file could have been more detailed/co-located (perhaps a small example file?) and a mention of the excludelist may be helpful.. Overall I think the main problem with the docs is that the information is too spread out or too deep. I would suggest a very simple/explicit explanation first with more details following. For example, the docs show many different ways to create an AppImage (twice in the same spot actually). I think it would help to start out with just one example that explains how the process should work (possibly a manual build) to help users get an idea of what they are actually needing to do.

All that being said I am still hugely appreciative of the work you and others have done to create the amazing tool that is AppImage. If you think that you may be interested, I would be willing to come up with my own documentation and tutorial and present it to you. An outside perspective may be more valuable for documentation as outsiders may have a much lesser working knowledge of the application and would be less likely to leave out/misplace important but small details that the creators know from memory.

probonopd commented 6 years ago

If you think that you may be interested, I would be willing to come up with my own documentation and tutorial and present it to you. An outside perspective may be more valuable for documentation as outsiders may have a much lesser working knowledge of the application and would be less likely to leave out/misplace important but small details that the creators know from memory.

Exactly. That would be terrific! :+1:

ghost commented 6 years ago

@probonopd awesome! I'll write something up and get back to you soon.

TheAssassin commented 6 years ago

@rucuriousyet feel free to post your tutorial in our wiki, too.

ghost commented 6 years ago

Okay, I've been sick for a couple days but I'll make sure to finish it up today

-sent from my OnePlus X

On Jan 25, 2018 8:02 AM, "TheAssassin" notifications@github.com wrote:

@rucuriousyet https://github.com/rucuriousyet feel free to post your tutorial in our wiki, too.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/AppImage/AppImageKit/issues/629#issuecomment-360460303, or mute the thread https://github.com/notifications/unsubscribe-auth/AIIciDGHS0vXk8AxfamWUz4XnmtBOBedks5tOHtcgaJpZM4Rgjsk .

TheAssassin commented 6 years ago

Thanks. There's no rush, take your time.

ghost commented 6 years ago

appimageTutorial.txt Here's what I have at the moment.... I've been sick and also very busy so I didn't have the time I was hoping for to work on this. Let me know what you think, It's a very rough draft, I wrote it from the perspective that it would be posted on my blog so that may be something in need of change. Also, FWIW, I am NOT a writer LOL

BTW, it wouldn't let me attach this file as markdown... I recommend reading in a markdown viewer after changing the extension to .md

ghost commented 6 years ago

For your reading pleasure, I've created an unpublished preview of this on my blog: https://blog.eistudios.org/p/65005317-7d18-45df-afc5-3e6a5649a56d/

probonopd commented 6 years ago

Thanks @rucuriousyet. I am sure others, especially @KurtPfeifle who is an experienced technical writer will have more comments, but here is what I noticed at first glance:

AppImage is not a package format. It's "application images", like "disk images" containing applications on the Mac
"the installation process is instant" - well, the point is that there is no "installation" step
AppImageTool does not exist. It is a command line tool and hence lowercase appimagetool
"easily determine what libraries our application requires by running ldd <executable>" - why do all that hard work by hand if linuxdeployqt can do it for you?
$LD_LIBRARY_PATH is something we want to avoid if possible, since it can cause issues when applications inside the AppImage launch applications outside the AppImage. linuxdeployqt patches the rpath instead
"It's highly recommended to use older versions of Ubuntu (such as 14.04)". This cannot be stressed enough. It is not something specific to AppImage, but in general an application will not run on an OS that is older than the one it was compiled on. Hence we recommend to use no newer OSes than the oldest still-supported Long Term Support release, which at this point is 14.04

ghost commented 6 years ago

All good points... I think the manual AppRun creation helps the developer to understand how AppImages work without diving into too much complexity. I'll definitely make some changes to reflect what you've mentioned (probably sometime tomorrow).

ghost commented 6 years ago

Would "application imaging format" be more accurate? Not sure exactly how to present that. I would think to compare it to packaging formats like .deb, .rpm etc.

TheAssassin commented 6 years ago

I'd call it "application bundles". Users don't care how something like AppImage work technically, whether it's an archive, an image, etc.

azubieta commented 5 years ago

Closing the issue due inactivity. Please reopen if required.

probonopd commented 5 years ago

@rucuriousyet I think all of your needs can be addressed by writing a custom AppRun script; let me know if you'd like some help on that.

AppImage / AppImageKit

Issues with Love2D #629