Can't get this compiled on Ubuntu 14.04

[probonopd]

Can't get this compiled on Ubuntu 14.04:

g++: error: unrecognized command line option ‘-std=c++1z’
g++: error: unrecognized command line option ‘-Wabi=11’
g++: error: unrecognized command line option ‘-fsanitize=undefined’
make: *** [main.o] Error 1
make: *** Waiting for unfinished jobs....
g++: error: unrecognized command line option ‘-std=c++1z’
g++: error: unrecognized command line option ‘-Wabi=11’
g++: error: unrecognized command line option ‘-fsanitize=undefined’
make: *** [mainwindow.o] Error 1
rm ui_mainwindow.hh

References:

• https://github.com/probonopd/lilyplayer/blob/patch-1/.travis.yml
• https://travis-ci.org/probonopd/lilyplayer/builds/405055278#L545-L554

[s-d-m]

Hi @probonopd

Thanks for the report.
The minimum version of gcc required to compile lilyplayer is gcc-5. Your logs mention that you tried to compile it with gcc-4.8.

Documentation should have been clearer. Sorry

[probonopd]

Thanks for this advice. Now running into mainwindow.hh:15:27: fatal error: rtmidi/RtMidi.h: No such file or directory despite librtmidi-dev being installed.

Reference:
https://travis-ci.com/probonopd/lilyplayer/builds/79357626#L771

[probonopd]

Running into more errors when symlinking this in:
https://travis-ci.com/probonopd/lilyplayer/builds/79358991#L778

Does it work with the version of rtmidi in Ubuntu 14.04? Or could the requirement be lowered to work with the version in Ubuntu 14.04?

[s-d-m]

@probonopd

I never tried compiling and running it on ubuntu 14.04 before.
The requirements can be lowered to support it though.
I wanted to use appimages especially so that users could have a nice binary without having to support many distributions (issue of limited time / resources ...)

I will try to find some time this week-end to make it compile and work on ubuntu 14.04 if you want.

In the mean time, I did create a small mini-app yesterday that compiles and work on ubuntu 14.04 and for which the issue alamminsalo/orion#48 is reproduced. That mini-app is available at https://github.com/s-d-m/github_as_free_public_storage/blob/master/minimum_failing_app_for_linuxqtdeploy.tar.bz2

Let me know if there is anything else I can do.

[probonopd]

I wanted to use appimages especially so that users could have a nice binary without having to support many distributions (issue of limited time / resources ...)

This is exactly what AppImage is for. To make sure your AppImage will run on most still-supported Linux distributions out there (and not just on the latest ones), it is best practice to target the application for the oldest still-supported long time support releases of distributions (e.g., currently Ubuntu 14.04 LTS).

So yes, it would be great if you could make it compile there. Thanks!

In the mean time, I did create a small mini-app

Thanks, but it's not in its own repo so it's not easy for me to work with.

Let me know if there is anything else I can do.

Let's do the real thing, lilyplayer.

[s-d-m]

Hi @probonopd

I updated my branch and now it compiles and works on ubuntu 14.04 ... with some help of your tavis.yml file. I added rtmidi directly in the repository as a submodule to avoid working with distribution-specific versions. That means the instructions to install are a bit different now. Also the list of dependencies to install are now bigger. Your travis.yml will need to be updated.

To install:

sudo apt-get install libqt5widgets5 libqt5gui5 libqt5core5a qt5-default qt5-qmake g++-5 libqt5svg5 libqt5svg5-dev  gawk sed autoconf libtool libasound2-dev

Note that you install timidity in your travis.yml. It isn't required to build or run lilyplayer. It is required if the user wants to hear something "only".

Right now I needed to copy the rtmidi libraries from 3rd-party/rtmidi/.libs to /usr/lib first. (didn't get time to fix that).
Running lilypond directly fails because qt-libraries complains about 'no version information available'. However when making the appimage and then running it, it just works! (it still calls things from the environment though).

In the mean time, I did create a small mini-app
Thanks, but it's not in its own repo so it's not easy for me to work with.

The idea was to give you something small enough to become a regression test in linuxqtdeploy test suite. It has no librtmidi dependency for example. And compiles with gcc-4.8. If it is only about putting it in its own repo, that's a no brainer, simply untar it and push the directory to github (or somewhere else). I can keep the repo in my github if you want.

Let's do the real thing, lilyplayer.
Getting there, just a few modifications to the travis.yml ...

[s-d-m]

Hi @probonopd,

I saw you kept going on this. Thanks. I created a second branch where I mostly copy/pasted your travis.yml file as it felt easier than integrating your branch just for testing. If github contributions are important to you, I will obviously be happy to merge your branch.

Anyway, i managed to get the appimage created by travis, and at the end, it shows:

The command "./squashfs-root/usr/bin/appimagetool -g ./appdir/ Lilyplayer-$VERSION-x86_64.AppImage" exited with 0.
$ find appdir -executable -type f -exec ldd {} \; | grep " => /usr" | cut -d " " -f 2-3 | sort | uniq
=> /usr/lib/x86_64-linux-gnu/libasound.so.2
=> /usr/lib/x86_64-linux-gnu/libdrm.so.2
=> /usr/lib/x86_64-linux-gnu/libglapi.so.0
=> /usr/lib/x86_64-linux-gnu/libstdc++.so.6
=> /usr/lib/x86_64-linux-gnu/libX11.so.6
=> /usr/lib/x86_64-linux-gnu/libX11-xcb.so.1
=> /usr/lib/x86_64-linux-gnu/libXau.so.6
=> /usr/lib/x86_64-linux-gnu/libxcb-dri2.so.0
=> /usr/lib/x86_64-linux-gnu/libxcb-dri3.so.0
=> /usr/lib/x86_64-linux-gnu/libxcb-glx.so.0
=> /usr/lib/x86_64-linux-gnu/libxcb-present.so.0
=> /usr/lib/x86_64-linux-gnu/libxcb.so.1
=> /usr/lib/x86_64-linux-gnu/libxcb-sync.so.1
=> /usr/lib/x86_64-linux-gnu/libXdamage.so.1
=> /usr/lib/x86_64-linux-gnu/libXdmcp.so.6
=> /usr/lib/x86_64-linux-gnu/libXext.so.6
=> /usr/lib/x86_64-linux-gnu/libXfixes.so.3
=> /usr/lib/x86_64-linux-gnu/libxshmfence.so.1
=> /usr/lib/x86_64-linux-gnu/libXxf86vm.so.1
=> /usr/lib/x86_64-linux-gnu/mesa/libGL.so.1

as you can see at https://travis-ci.org/s-d-m/lilyplayer/builds/406672160?utm_source=github_status&utm_medium=notification

Should we copy paste these libraries into appdir/usr/lib before creating the appimage?

[probonopd]

This means that only those libraries are used from the base system. Looks good to me. Do you have a download link for your AppImage? (Looks like if you had a GITHUB_TOKEN set up as per the uploadtool documentation, it might have worked...)

https://travis-ci.org/s-d-m/lilyplayer/builds/406672160#L1270

[s-d-m]

Isn't that a bug? I thought the goal of appimages was to not rely on system's library at all. Or these libraries system-dependant somehow?

[probonopd]

We recommend to not bundle these libraries, but to use them from the system.

[probonopd]

Looking good. Tested my build from https://travis-ci.com/probonopd/lilyplayer/builds/79659508#L1271 and it is "almost" working, saying

==16050==ASan runtime does not come first in initial library list; you should either link runtime to your application or manually preload it with LD_PRELOAD.

How to "link runtime to application"?

[s-d-m]

I believe it means statically linking the address sanitiser library.

The workaround would be to not compile with asan. I'm looking into it now.

[s-d-m]

works now!

There is only one little thing I just can't get right so far: the icon.
On ubuntu, when pressing alt+tab to switch through windows, instead of seeing my icon, I get the generic question mark.

Is there something I'm missing with the appimage desktop file? Should the icon be an svg file?

[s-d-m]

Hi @probonopd

I went ahead to also make appimages for lilydumper (the program that creates the music sheets for lilyplayer to play). And I think there is something wrong.

linuxqtdeploy doesn't bundle the libpugixml. That is an xml library which is not listed in the exclude list (and I don't see why it should).

The travis logs are available at https://travis-ci.org/s-d-m/lilydumper/builds/406875777 and the code is available at https://github.com/s-d-m/lilydumper/commits/create-appimage-with-travis

Is this a bug in linuxqtdeploy? or am I supposed to copy the library into the appdir by hand?

[probonopd]

There is only one little thing I just can't get right so far: the icon.

Please use QApplication::setWindowIcon(), then it will work.

[probonopd]

linuxqtdeploy doesn't bundle the libpugixml.

Please run linuxdeployqt -verbose=2 ...

[s-d-m]

looks like the last command showing which libraries are still used on the system doesn't work.

libpugixml is actually packaged. The appimage still runs if I remove libpugixml completely from the system, and the logs below confirms it

  linuxdeployqt 4 (commit ac2d5c2), build 561 built on 2018-07-09 18:54:52 UTC
Desktop file as first argument: "/tmp/DIR_TO_MAKE_AN_APPIMAGE_FOR_LILYDUMPER.0cOwRw/usr/share/applications/lilydumper.desktop"
desktopExecEntry: "lilydumper"
desktopIconEntry: "lilydumper"
Found binary from desktop file: "/tmp/DIR_TO_MAKE_AN_APPIMAGE_FOR_LILYDUMPER.0cOwRw/usr/bin/lilydumper"
FHS-like mode with PREFIX, fhsPrefix: "/tmp/DIR_TO_MAKE_AN_APPIMAGE_FOR_LILYDUMPER.0cOwRw/usr"
app-binary: "/tmp/DIR_TO_MAKE_AN_APPIMAGE_FOR_LILYDUMPER.0cOwRw/usr/bin/lilydumper"
appDirPath: "/tmp/DIR_TO_MAKE_AN_APPIMAGE_FOR_LILYDUMPER.0cOwRw"
relativeBinPath: "usr/bin/lilydumper"
Copied "/tmp/DIR_TO_MAKE_AN_APPIMAGE_FOR_LILYDUMPER.0cOwRw/usr/share/applications/lilydumper.desktop" to "/tmp/DIR_TO_MAKE_AN_APPIMAGE_FOR_LILYDUMPER.0cOwRw/lilydumper.desktop"
Found icons from desktop file: ("/tmp/DIR_TO_MAKE_AN_APPIMAGE_FOR_LILYDUMPER.0cOwRw/usr/share/applications/hicolor/256x256/apps/lilydumper.png")
iconToBeUsed: "/tmp/DIR_TO_MAKE_AN_APPIMAGE_FOR_LILYDUMPER.0cOwRw/usr/share/applications/hicolor/256x256/apps/lilydumper.png"
Copied "/tmp/DIR_TO_MAKE_AN_APPIMAGE_FOR_LILYDUMPER.0cOwRw/usr/share/applications/hicolor/256x256/apps/lilydumper.png" to "/tmp/DIR_TO_MAKE_AN_APPIMAGE_FOR_LILYDUMPER.0cOwRw/lilydumper.png"
Log: Deploying the following libraries: ("/tmp/DIR_TO_MAKE_AN_APPIMAGE_FOR_LILYDUMPER.0cOwRw/usr/bin/lilydumper")
Log:  copied: "/usr/lib/x86_64-linux-gnu/libpugixml.so.1"
Log:  to "/tmp/DIR_TO_MAKE_AN_APPIMAGE_FOR_LILYDUMPER.0cOwRw/usr/lib///libpugixml.so.1"
Log:  copied: "/usr/share/doc/libpugixml1v5/copyright"
Log:  to "/tmp/DIR_TO_MAKE_AN_APPIMAGE_FOR_LILYDUMPER.0cOwRw/usr/share/doc/libpugixml1v5/copyright"
Log: Checking rpath in "/tmp/DIR_TO_MAKE_AN_APPIMAGE_FOR_LILYDUMPER.0cOwRw/usr/lib/libpugixml.so.1"
Log: Changing rpath in "/tmp/DIR_TO_MAKE_AN_APPIMAGE_FOR_LILYDUMPER.0cOwRw/usr/lib/libpugixml.so.1" to "$ORIGIN"
Log: Checking rpath in "/tmp/DIR_TO_MAKE_AN_APPIMAGE_FOR_LILYDUMPER.0cOwRw/usr/bin/lilydumper"
Log: Changing rpath in "/tmp/DIR_TO_MAKE_AN_APPIMAGE_FOR_LILYDUMPER.0cOwRw/usr/bin/lilydumper" to "$ORIGIN/../lib"
ERROR: runPatchelf: "warning: working around a Linux kernel bug by creating a hole of 13049856 bytes in \xE2\x80\x98/tmp/DIR_TO_MAKE_AN_APPIMAGE_FOR_LILYDUMPER.0cOwRw/usr/bin/lilydumper\xE2\x80\x99\nmaximum file size exceeded\n"
appimagetool, continuous build (commit 07100fb), build 1769 built on 2018-07-04 13:41:03 UTC

I do have over issues however.
When I run ./lilydumper-appimage -i some_file it fails saying it can't copy the file. But if I put the full path to some_file, that works. Does appimages run the program under a different path?

Also, lilydumper executes lilypond changing the environment. In particular it sets LD_PRELOAD. And when running the appimage, it looks like setting the environment before execution a program doesn't work. Is this something supported? Looking at AppImage/AppImageKit#396 it looks like this is disabled. Is there a way to get it back?

[probonopd]

Please run sudo strace -f ./lilydumper-appimage -i some_file 2>&1 | grep some_file to see what is going on there.

[probonopd]

Also, lilydumper executes lilypond changing the environment. In particular it sets LD_PRELOAD. And when running the appimage, it looks like setting the environment before execution a program doesn't work.

Not that I'd know.

Looking at AppImage/AppImageKit#396 it looks like this is disabled.

Not sure what you mean by "this is disabled", can you elaborate?

[s-d-m]

When googling a bit about my issue, I found out there was some discussions about resetting the environment before executing an application that is outside the appimage.
Such that if I set the environment in my program for lilypond, the appimage runtime would overwrite my changes.

To be honest, I just skimmed quickly on these.

The result of running with strace:
When running without sudo, it can't mount the appimage.
when running with sudo, it hangs and the logs are not so useful.

However these issues were related to the workaround for older system. Removing that made the appimage works ... on my dev machine. On Ubuntu 14.04 it complains about a missing libpugixml and missing symbols in libstdc++.so.6 (which is taken from the system).

I'm compiling using g++6 because my code hits an internal compiler error with gcc5.

[probonopd]

However these issues were related to the workaround for older system.

This workaround is needed. Please describe the problem it generates in a new ticket on https://github.com/darealshinji/AppImageKit-checkrt/issues and please provide a way to reproduce it. Thanks.

[s-d-m]

will try to find some time during the week to create a small app with the same issue,

In the mean time, simply copying the libraries into the squash-fs and setting the rpath with patchelf is enough to provide a working appimage. Too bad patchelf is not packaged in ubuntu 14.04...

[probonopd]

Too bad patchelf is not packaged in ubuntu 14.04...

You can use the one contained inside the appimagetool AppImage.

[s-d-m]

seems like that one doesn't work.
simply replacing patchelf by the one that I get inside "$linuxqtdeploy" --appimage-extract doesn't do the same thing.

I ended up taking the one from nixos, untar it and compile and install in the travis.yml to produce a working appimage.
I didn't get time to investigate more on these issues though

[s-d-m]

closing this issue as I'm not working on this since a long time.