Giter VIP home page Giter VIP logo

probonopd / linuxdeployqt Goto Github PK

View Code? Open in Web Editor NEW
2.1K 75.0 401.0 746 KB

Makes Linux applications self-contained by copying in the libraries and plugins that the application uses, and optionally generates an AppImage. Can be used for Qt and other applications

License: Other

QMake 2.67% C++ 83.76% Shell 7.30% QML 2.26% Prolog 0.01% CMake 2.47% Dockerfile 0.36% C 1.16%
qt qt5 packaging deployment applications appimage linux

linuxdeployqt's Introduction

linuxdeployqt Build Status Downloads discourse Gitter irc

Please note: As of 2024 , I am no longer actively working on this codebase in favor of https://github.com/probonopd/go-appimage.

This Linux Deployment Tool, linuxdeployqt, takes an application as input and makes it self-contained by copying in the resources that the application uses (like libraries, graphics, and plugins) into a bundle. The resulting bundle can be distributed as an AppDir or as an AppImage to users, or can be put into cross-distribution packages. It can be used as part of the build process to deploy applications written in C, C++, and other compiled languages with systems like CMake, qmake, and make. When used on Qt-based applications, it can bundle a specific minimal subset of Qt required to run the application.

Differences to macdeployqt

This tool is conceptually based on the Mac Deployment Tool, macdeployqt in the tools applications of the Qt Toolkit, but has been changed to a slightly different logic and other tools needed for Linux.

  • Instead of an .app bundle for macOS, this produces an AppDir for Linux
  • Instead of a .dmg disk image for macOS, this produces an AppImage for Linux which is quite similar to a dmg but executes the contained application rather than just opening a window on the desktop from where the application can be launched

A note on binary compatibility

To produce binaries that are compatible with many target systems, build on the oldest still-supported build system. The oldest still-supported release of Ubuntu is currently targeted, tested and supported by the team.

We recommend to target the oldest still-supported Ubuntu LTS release and build your applications on that. If you do this, the resulting binaries should be able to run on newer (but not older) systems (Ubuntu and other distributions).

linuxdeployqt refuses to work on systems any newer than the oldest currently still-supported Ubuntu LTS release, because we want to encourage developers to build applications in a way that makes them possible to run on all still-supported distribution releases. For an overview about the support cycles of Ubuntu LTS releases, please see https://wiki.ubuntu.com/Releases. If you absolutely need to build your application on a build system newer than the oldest currently still-supported Ubuntu LTS release, then consider using go-appimage appimagetool -s deploy (unlike linuxdeployqt, this bundles all libraries).

linuxdeployqt does not contain any specific workarounds for Wayland which breaks many things. For best results, do not use Wayland.

Installation

Please download linuxdeployqt-x86_64.AppImage from the Releases page and chmod a+x it. If you would like to build linuxdeployqt from source instead, see BUILDING.md.

Usage

Usage: linuxdeployqt <app-binary|desktop file> [options]

Options:
   -always-overwrite        : Copy files even if the target file exists.
   -appimage                : Create an AppImage (implies -bundle-non-qt-libs).
   -bundle-non-qt-libs      : Also bundle non-core, non-Qt libraries.
   -exclude-libs=<list>     : List of libraries which should be excluded,
                              separated by comma.
   -ignore-glob=<glob>      : Glob pattern relative to appdir to ignore when
                              searching for libraries.
   -executable=<path>       : Let the given executable use the deployed libraries
                              too
   -executable-dir=<path>   : Let all the executables in the folder (recursive) use
                              the deployed libraries too
   -extra-plugins=<list>    : List of extra plugins which should be deployed,
                              separated by comma.
   -no-copy-copyright-files : Skip deployment of copyright files.
   -no-plugins              : Skip plugin deployment.
   -no-strip                : Don't run 'strip' on the binaries.
   -no-translations         : Skip deployment of translations.
   -qmake=<path>            : The qmake executable to use.
   -qmldir=<path>           : Scan for QML imports in the given path.
   -qmlimport=<path>        : Add the given path to QML module search locations.
   -show-exclude-libs       : Print exclude libraries list.
   -verbose=<0-3>           : 0 = no output, 1 = error/warning (default),
                              2 = normal, 3 = debug.
   -updateinformation=<update string>        : Embed update information STRING; if zsyncmake is installed, generate zsync file
   -version                 : Print version statement and exit.

linuxdeployqt takes an application as input and makes it
self-contained by copying in the Qt libraries and plugins that
the application uses.

By default it deploys the Qt instance that qmake on the $PATH points to.
The '-qmake' option can be used to point to the qmake executable
to be used instead.

Plugins related to a Qt library are copied in with the library.

See the "Deploying Applications on Linux" topic in the
documentation for more information about deployment on Linux.

Simplest example

You'll need to provide the basic structure of an AppDir which should look something like this:

└── usr
    ├── bin
    │   └── your_app
    ├── lib
    └── share
        ├── applications
        │   └── your_app.desktop
        └── icons
            └── <theme>
                └── <resolution> 
                    └── apps 
                        └── your_app.png

Replace <theme> and <resolution> with (for example) hicolor and 256x256 respectively; see icon theme spec for more details.

Using the desktop file linuxdeployqt can determine the parameters of the build.

Where your desktop file would look something like:

[Desktop Entry]
Type=Application
Name=Amazing Qt App
Comment=The best Qt Application Ever
Exec=your_app
Icon=your_app
Categories=Office;
  • Notice that both Exec and Icon only have file names.
  • Also Notice that the Icon entry does not include an extension.

Read more about desktop files in the Desktop Entry Specification 1.0.

Now you can say: linuxdeployqt-continuous-x86_64.AppImage path/to/AppDir/usr/share/applications/your_app.desktop

For a more detailed example, see "Using linuxdeployqt with Travis CI" below.

Checking library inclusion

Open in Qt Creator and build your application. Run it from the command line and inspect it with ldd to make sure the correct libraries from the correct locations are getting loaded, as linuxdeployqt will use ldd internally to determine from where to copy libraries into the bundle.

QMake configuration

Important: By default, linuxdeployqt deploys the Qt instance that qmake on the $PATH points to, so make sure that it is the correct one. Verify that qmake finds the correct Qt instance like this before running the linuxdeployqt tool:

qmake -v

QMake version 3.0
Using Qt version 5.7.0 in /tmp/.mount_QtCreator-5.7.0-x86_64/5.7/gcc_64/lib

If this does not show the correct path to your Qt instance that you want to be bundled, then adjust your $PATH to find the correct qmake.

Alternatively, use the -qmake command line option to point the tool directly to the qmake executable to be used.

Remove unnecessary files

Before running linuxdeployqt it may be wise to delete unneeded files that you do not wish to distribute from the build directory. These may be autogenerated during the build. You can delete them like so:

find $HOME/build-*-*_Qt_* \( -name "moc_*" -or -name "*.o" -or -name "qrc_*" -or -name "Makefile*" -or -name "*.a" \) -exec rm {} \;

Alternatively, you could use $DESTDIR.

Adding icon and icon theme support

To enable icon and icon theme support you must add iconengines as an extra Qt plugin while running linuxdeployqt. In order for your application to locate the system theme icons, the libqgtk3.so platform theme must also be added:

-extra-plugins=iconengines,platformthemes/libqgtk3.so

Adding extra Qt plugins

If you want aditional plugins which the tool doesn't deploy, for a variety of reasons, you can use the -extra-plugins argument and include a list of plugins separated by a comma.
The plugins deployed are from the Qt installation pointed out by qmake -v.
You can deploy entire plugin directories, a specific directory or a mix of both.

Usage examples:

  1. -extra-plugins=sqldrivers/libqmsql.so,iconengines/libqsvgicon.so
  2. -extra-plugins=sqldrivers,iconengines/libqsvgicon.so
  3. -extra-plugins=sqldrivers,iconengines,mediaservice,gamepads

Handle Qt libraries infix

If you prepared a custom Qt distribution using the option -qtlibinfix during Qt configuration (resulting in library names such as libQt5CoreCustom.so), you must mention this infix on linuxdeployqt call. As an example, let's see if we configure our distribution using the infix Custom.

On Qt build chain: configure -qtlibinfix "Custom" [...]. This will generate Qt libraries (.so) like libQt5CoreCustom.so

So, on linuxdeployqt call: linuxdeployqt [...] -qtlibinfix "Custom" [...].

If you don't mention this infix, linuxdeployqt won't be able to detect Qt Core and Widgets libraries.

Fix for "make: Nothing to be done for 'install'"

If qmake does not allow for make install or does not install the desktop file and icon, then you need to change your .pro file it similar to https://github.com/probonopd/FeedTheMonkey/blob/master/FeedTheMonkey.pro.

Here is another simple example.

It is common on Unix to also use the build tool to install applications and libraries; for example, by invoking make install. For this reason, qmake has the concept of an install set, an object which contains instructions about the way a part of a project is to be installed.

Please see the section "Installing Files" on http://doc.qt.io/qt-5/qmake-advanced-usage.html.

For projects that use CMake, autotools, or meson with ninja instead of qmake

  - make INSTALL_ROOT=appdir install ; find appdir/

CMake wants DESTDIR instead:

  - cmake . -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=/usr
  - make -j$(nproc)
  - make DESTDIR=appdir -j$(nproc) install ; find appdir/

Some applications have the bad habit of relying on CMake versions newer than what comes with the oldest still-supported distributions. In this case, install a newer CMake with

  - sudo rm -rf /usr/bin/cmake /usr/local/cmake-* /usr/local/bin/cmake || true # Needed on Travis CI; don't do this on other systems!
  - wget "https://github.com/Kitware/CMake/releases/download/v3.13.2/cmake-3.13.2-Linux-x86_64.tar.gz" ; sudo tar xf  cmake*.tar.gz --strip-components=1 -C /usr

Under some circumstances it may also be required to add -DCMAKE_INSTALL_LIBDIR=/usr/lib to the cmake call.

autotools (the dinosaur that spends precious minutes "checking...") wants DESTDIR too but insists on an absolute link which we can feed it using readlink:

  - ./configure --prefix=/usr
  - make -j$(nproc)
  - make install DESTDIR=$(readlink -f appdir) ; find appdir/

Caution if you encounter

qmake PREFIX=/usr CONFIG+=use_qt_paths

Here, CONFIG+=use_qt_paths needs to be removed, otherwise it will install everything under the Qt installation paths in /opt/qt58 when using the beineri ppa.

The exception is that you are building Qt libraries that should be installed to the same location where Qt resides on your system, from where it will be picked up by linuxdeployqt.

meson with ninja apparently wants

  - meson --prefix /usr build
  - ninja -C build
  - DESTDIR=./appdir ninja -C build install ; find build/appdir

When using Qt from distribution packages

On Ubuntu 14.04, you will need to pass in -qmake=/usr/lib/x86_64-linux-gnu/qt5/bin/qmake when using distribution packages.

A note on DESTDIR

According to https://dwheeler.com/essays/automating-destdir.html,

Automating DESTDIR can be a pain, so it’s best if the program supports it to start with; my package Auto-DESTDIR can automatically support DESTDIR in some cases if the program installation does not support it to begin with.

Also see https://www.gnu.org/prep/standards/html_node/DESTDIR.html for more information.

Sending Pull Requests on GitHub

linuxdeployqt is great for upstream application projects that want to release their software in binary form to Linux users quickly and without much overhead. If you would like to see a particular application use linuxdeployqt, then sending a Pull Request may be an option to get the upstream application project to consider it. You can use the following template text for Pull Requests but make sure to customize it to the project in question.

This PR, when merged, will compile this application on [Travis CI](https://travis-ci.org/) upon each `git push`, and upload an [AppImage](http://appimage.org/) to your GitHub Releases page.

Providing an [AppImage](http://appimage.org/) would have, among others, these advantages:
- Applications packaged as an AppImage can run on many distributions (including Ubuntu, Fedora, openSUSE, CentOS, elementaryOS, Linux Mint, and others)
- One app = one file = super simple for users: just download one AppImage file, [make it executable](http://discourse.appimage.org/t/how-to-make-an-appimage-executable/80), and run
- No unpacking or installation necessary
- No root needed
- No system libraries changed
- Works out of the box, no installation of runtimes needed
- Optional desktop integration with `appimaged`
- Optional binary delta updates, e.g., for continuous builds (only download the binary diff) using AppImageUpdate
- Can optionally GPG2-sign your AppImages (inside the file)
- Works on Live ISOs
- Can use the same AppImages when dual-booting multiple distributions
- Can be listed in the [AppImageHub](https://appimage.github.io/) central directory of available AppImages
- Can double as a self-extracting compressed archive with the `--appimage-extract` parameter
- No repositories needed. Suitable/optimized for air-gapped (offline) machines
- Decentralized

[Here is an overview](https://appimage.github.io/apps) of projects that are already distributing upstream-provided, official AppImages.

__PLEASE NOTE:__ For this to work, you need to set up `GITHUB_TOKEN` in Travis CI for this to work; please see https://github.com/probonopd/uploadtool.
If you would like to see only one entry for the Pull Request in your project's history, then please enable [this GitHub functionality](https://help.github.com/articles/configuring-commit-squashing-for-pull-requests/) on your repo. It allows you to squash (combine) the commits when merging.

If you have questions, AppImage developers are on #AppImage on irc.freenode.net.

Projects using linuxdeployqt

These projects are already using Travis CI and linuxdeployqt to provide AppImages of their builds:

These projects are using GitHub Actions and linuxdeployqt to provide AppImages of their builds:

This project is already using linuxdeployqt in a custom Jenkins workflow:

This GitHub template invokes linuxdeployqt during a GitHub CI Action:

These projects are already using linuxdeployqt:

This project on GitLab uses linuxdeployqt:

This project can be bundled successfully using linuxdeployqt:

Contributing

One great way to contribute is to send Pull Requests to the application projects you'd like to see use linuxdeployqt, as described above. You are also welcome to contribute to linuxdeployqt development itself. Please discuss in the forum or using GitHub issues and Pull Requests.

Contact

The developers are in the channel #AppImage on irc.freenode.net

linuxdeployqt's People

Contributors

adrianschroeter avatar afiestas avatar atehxx avatar atsushi-yamamoto-signalslot avatar bjorn avatar darksknight avatar drdub avatar hkollmann avatar kefir500 avatar krzemin avatar mhoeher avatar mkrautz avatar nissimbendanan avatar osemmler avatar patrickelectric avatar pbek avatar pcolby avatar pestophagous avatar probonopd avatar ricciardi-adrien avatar saidinesh5 avatar skycoder42 avatar tcladet avatar theassassin avatar tobtoht avatar tresf avatar ubruhin avatar uwehermann avatar vadrian89 avatar vaibhavpandeyvpz avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

linuxdeployqt's Issues

Stripping not working

Hi

For RedTimer (https://github.com/fathomssen/redtimer), I create an AppImage, deb and rpm for Linux. The latter ones, I create using fpm according to the instructions in issue #9.

Now, lintian tells me that the binaries in the deb file have not been stripped:

$ lintian redtimer-v1.2-pre20-linux-x86_64.deb
E: redtimer: unstripped-binary-or-object opt/redtimer/redtimer
E: redtimer: unstripped-binary-or-object opt/redtimer/redtimercli
...

I used the following steps to generate the deb file (note that I DID NOT use -no-strip):

mkdir dist/opt/redtimer

cp gui/redtimer dist/opt/redtimer
cp cli/redtimercli dist/opt/redtimer

linuxdeployqt.AppImage dist/opt/redtimer/redtimer -qmldir=gui/qml
linuxdeployqt.AppImage dist/opt/redtimer/redtimercli -qmldir=gui/qml

fpm -s dir -t deb -m "..." --description "..." -n redtimer -v 1.2-pre20 -C dist -p redtimer-v1.2-pre20-linux-x86_64.deb

Best regards
Frederick Thomssen

Set qt_prfxpath=.

windeployqt unpatches (i.e. neuters) Qt's installation path in Qt5Core.dll.
So perhaps linuxdeployt could do the same, i.e. neuter the path to my Qt installation (e.g. change prfxpath=/home/henry/Qt/5.7/gcc_64 to prfxpath=. in libQt5Core.so.

getBinaryRPaths is broken

getBinaryRPaths using patchelf --print-rpath somehow doesn't work yet. In an earlier version I was using objdump which worked:

QSet<QString> getBinaryRPaths(const QString &path, bool resolve = true, QString executablePath = QString())
{
    QSet<QString> rpaths;

    QProcess otool;
    otool.start("objdump", QStringList() << "-x" << path);
    otool.waitForFinished();

    if (otool.exitCode() != 0) {
        LogError() << "getBinaryRPaths:" << otool.readAllStandardError();
    }

    if (resolve && executablePath.isEmpty()) {
      executablePath = path;
    }

    QString output = otool.readAllStandardOutput();
    QStringList outputLines = output.split("\n");
    QStringListIterator i(outputLines);

    while (i.hasNext()) {
        if (i.next().contains("RUNPATH") && i.hasNext()) {
            i.previous();
            const QString &rpathCmd = i.next();
            int pathStart = rpathCmd.indexOf("RUNPATH");
            if (pathStart >= 0) {
                QString rpath = rpathCmd.mid(pathStart+8).trimmed();
                LogDebug() << "rpath:" << rpath;
                rpaths << rpath;
            }
        }
    }

    return rpaths;
}

Would still prefer to use patchelf --print-rpath.

Remove ldd to allow for bundling cross-compiled applications

(Based on the tread on qt-devel)

Remove ldd to allow for bundling cross-compiled applications. ldd not only provides the name of the libraries to be loaded, but also the paths to the locations where they are loaded from. We have to recreate this manually:

implement the transitiveness by running it on each library.

First, use the environment variable $LD_LIBRARY_PATH. The default search path
is known to qmake (variable $QMAKE_DEFAULT_LIBDIRS) and you can then search the
paths from (etc/ld.so.conf & /etc/ld.so.conf.d/*.

  • If DT_RUNPATH is present, check $LD_LIBRARY_PATH first and ignore DT_RPATH
  • if only DT_RPATH is present, check it before $LD_LIBRARY_PATH

If we're cross-compiling, we should have access to the path to the
sysroot, so we can find ld.so.conf there, e.g., /opt/poky/sysroots/x86_64-pokysdk-linux/etc/ld.so.conf.

-libpath seems to have no effect

Since the path to my plugins folder is at /usr/lib/qt/plugins but linuxdeployqt searches in the non-existent /usr/plugins (this is a separate problem I guess), I tried to pass the correct path via the -libpath option which seems to have no effect. This is what I did exactly:

I created a new folder, copied over a fresh build of my binary and ran:

linuxdeployqt-1-x86_64.AppImage [binary name] -appimage -verbose=2 -bundle-non-qt-libs -always-overwrite

After this I saw following output:

Log: Deploying plugins from "/usr/plugins"
ERROR: file copy failed from "/usr/plugins/platforms/libqxcb.so"
ERROR:  to "./plugins/platforms/libqxcb.so"
ERROR: file copy failed from "/usr/plugins/printsupport/libcupsprintersupport.so"
ERROR:  to "./plugins/printsupport/libcupsprintersupport.so"

I cleared the folder, copied the binary over again and ran the same command with higher verbosity and additional -libpath option:

linuxdeployqt-1-x86_64.AppImage [binary-name] -appimage -verbose=3 -bundle-non-qt-libs -always-overwrite -libpath=/usr/lib/qt/plugins

I received the same output (https://www.dropbox.com/s/6mtyhoo15pnuogn/linuxdeploylog.txt?dl=0) and my local plugins folder remained empty. I have heard about the issue of linuxdeployqt having to run twice sometimes, so I ran the same command again on the changed folder with no effect either.

My system is ArchLinux, kernel: 4.8.11-1.
qmake -v output:

QMake version 3.0
Using Qt version 5.7.0 in /usr/lib

qmake -query:

QT_SYSROOT:
QT_INSTALL_PREFIX:/usr
QT_INSTALL_ARCHDATA:/usr/lib/qt
QT_INSTALL_DATA:/usr/share/qt
QT_INSTALL_DOCS:/usr/share/doc/qt
QT_INSTALL_HEADERS:/usr/include/qt
QT_INSTALL_LIBS:/usr/lib
QT_INSTALL_LIBEXECS:/usr/lib/qt/libexec
QT_INSTALL_BINS:/usr/bin
QT_INSTALL_TESTS:/usr/tests
QT_INSTALL_PLUGINS:/usr/lib/qt/plugins
QT_INSTALL_IMPORTS:/usr/lib/qt/imports
QT_INSTALL_QML:/usr/lib/qt/qml
QT_INSTALL_TRANSLATIONS:/usr/share/qt/translations
QT_INSTALL_CONFIGURATION:/etc/xdg
QT_INSTALL_EXAMPLES:/usr/share/doc/qt/examples
QT_INSTALL_DEMOS:/usr/share/doc/qt/examples
QT_HOST_PREFIX:/usr
QT_HOST_DATA:/usr/lib/qt
QT_HOST_BINS:/usr/bin
QT_HOST_LIBS:/usr/lib
QMAKE_SPEC:linux-g++
QMAKE_XSPEC:linux-g++
QMAKE_VERSION:3.0
QT_VERSION:5.7.0

Bundling of plugins is not implemented yet

macdeployqt determines which plugins should be bundled by checking which Frameworks are being bundled. Since on Linux there are no Frameworks, we will use .so* libraries for deciding this instead.

Also, the names of the plugins to be bundled are different on Linux than on macOS.

This needs to be converted from macOS to Linux logic.

The relevant code stars with the line

The frameworks are searched for dependencies, which are also deployed.

xcbglintegrations does not get deployed (takes two runs)

cool-retro-term needs the xcbglintegrations plugins, but currently they don't get deployed. How can I know that an application needs the xcbglintegrations plugins?

Guessing based on looking at the libraries' strings,

  • Possibly if libQt5XcbQpa.so.5 gets deployed
  • Possibly if libQt5OpenGL gets deployed

The error is:

QXcbIntegration: Cannot create platform OpenGL context, neither GLX nor EGL are enabled
Failed to create OpenGL context for format QSurfaceFormat(version 2.0, options QFlags(), depthBufferSize 24, redBufferSize -1, greenBufferSize -1, blueBufferSize -1, alphaBufferSize 8, stencilBufferSize 8, samples -1, swapBehavior 2, swapInterval 1, profile  0) 
Aborted

Component metadata refers to a non-existing .desktop file.

I m running on Linux 4.4 , kubuntu 16.04 And Qt 5.7
I have an error during the validation of metadata..
I just run the following line :

 linuxdeployqt FastQt -appimage -no-strip

I get a first error which say me to rename application name in default.appdata.xml.
After doing this, I ran it again :

Here is my error :

build-FastQt-Desktop_Qt_5_7_0_GCC_64bit-Release linuxdeployqt FastQt -appimage -no-strip      
"/usr/local/bin/usr/bin:/home/sacha/Linux_data/Qt/5.7/gcc_64/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/home/sacha/Bioinfo/apps/bin:/home/sacha/miniconda3/bin"
app-binary: "FastQt"
WARNING: "./qt.conf" already exists, will not overwrite.
WARNING: To make sure the plugins are loaded from the correct location,
WARNING: please make sure qt.conf contains the following lines:
WARNING: [Paths]
WARNING:   Plugins = plugins
Desktop file: /media/sacha/Linux_data/dev/build-FastQt-Desktop_Qt_5_7_0_GCC_64bit-Release/default.desktop
Name: Application
Icon: default
Exec: AppRun %F
Comment: Edit this default file
Type: Application
Categories entry not found in desktop file
Categories: (null)
File used for determining architecture: /media/sacha/Linux_data/dev/build-FastQt-Desktop_Qt_5_7_0_GCC_64bit-Release/lib/libQt5Gui.so.5
Arch: 86_64
App name for filename: Application
dest_path: Application-x86_64.AppImage
DESTINATION not specified, so assuming Application-x86_64.AppImage
/media/sacha/Linux_data/dev/build-FastQt-Desktop_Qt_5_7_0_GCC_64bit-Release should be packaged as Application-x86_64.AppImage
AppStream upstream metadata found in usr/share/metainfo/default.appdata.xml
E - default.appdata.xml:default.desktop
    Component metadata refers to a non-existing .desktop file.

Validation failed.
Failed to validate AppStream information with appstreamcli

Here is the metafile :

<?xml version="1.0" encoding="UTF-8"?>
<component type="desktop">
  <id>default.desktop</id>
  <name>FastQt</name>
  <summary>Analyser of genomics FastQ file</summary>
  <developer_name>XXX: Insert Company or Developer Name</developer_name>
  <description>
  <p>
        tesr zjsdlf sdjf lisdfj slkfj flizae jfsldfj sd
sdlkfjsd lfksdj fsd zelr jsdlkf sjdf 
selkfjsd flksdfj eazr sdf sdf   
</p>
  <p>
   This should a second paragraph.
  </p>
</description>
  <metadata_license>XXX: Insert SPDX value here</metadata_license>
  <project_license>XXX: Insert SPDX value here</project_license>
  <url type="bugtracker">XXX: http://www.homepage.com/where-to-report_bug.html</url>
  <url type="donation">XXX: http://www.homepage.com/donation.html</url>
  <url type="faq">XXX: http://www.homepage.com/faq.html</url>
  <url type="help">XXX: http://www.homepage.com/docs/</url>
  <url type="homepage">XXX: http://www.homepage.com/</url>
  <screenshots>
    <screenshot type="default">
      <caption>XXX: Describe another screenshot</caption>
      <image height="630" width="1120">XXX: http://www.my-screenshot.png</image>
    </screenshot>
    <screenshot>
      <caption>XXX: Describe the default screenshot</caption>
      <image height="630" width="1120">XXX: http://www.my-screenshot-default.png</image>
    </screenshot>
  </screenshots>
</component>

linuxdeployqt and qtwebengine

Hi.
I use linuxdeployqt-x86_64.AppImage from the Releases page to transfer the program to another computer without Qt.

But when I run the program, it is crashes.
After searching the information I added icudtl.dat in the "resources" folder. The program is successfully launched.

Now I have a some errors:
Failed to load qtwebengine_resources.pak, qtwebengine_resources_100p.pak and qtwebengine_resources_200p.pak.
Then I added these files in the "resources" directory.

And
Installed Qt WebEngine locales directory not found at location .../qtwebengine_locales. Trying application directory...
Qt WebEngine locales directory not found at location .../qtwebengine_locales. Trying fallback directory... Translations MAY NOT not be correct.
[0116/112551:WARNING:resource_bundle.cc(291)] locale_file_path.empty() for locale
Then I added a "translation" into the root.

Now I have a some errors:
Qt WebEngine ICU data not found at /opt/Qt/Qt5.6.2/5.6/gcc_64. Trying fallback directory.
...
qml: render process terminated
qml: Render process exited with code -1 (crashed)

And WebEngineView page is empty.

Qt 5.6.2, Ubuntu 64bit.

Sometimes bundles the wrong Qt

When I build an application in Qt Creator, then it has its rpath point to the Qt directory that came with Qt Creator, and that was used for compiling the application.

linuxdeployqt should use that location as the source location when bundling libraries, but it doesn't and bundles Qt from the host system instead, which is guaranteed to break due to version mismatches. Possibly related to #1.

When building an app using Qt Creator, it looks like this:

ldd /home/me/build-untitled3-Desktop_Qt_5_7_0_GCC_64bit-Debug/untitled3
    linux-vdso.so.1 =>  (0x00007fff61bef000)
    libQt5Widgets.so.5 => /tmp/.mount_QtCreator-5.7.0-x86_64/5.7/gcc_64/lib/libQt5Widgets.so.5 (0x00007f7f27dcf000)
    libQt5Core.so.5 => /tmp/.mount_QtCreator-5.7.0-x86_64/5.7/gcc_64/lib/libQt5Core.so.5 (0x00007f7f276b4000)
    libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f7f27319000)
...

linuxdeployqt currently wrongly tries to bundle the system Qt from the rpath (/usr/lib rather than the one in /tmp/.mount_QtCreator-5.7.0-x86_64/5.7/gcc_64 from the example above):

Log: Deploying plugins from "/usr/lib/plugins"
ERROR: file copy failed from "/usr/lib/plugins/platforms/libqxcb.so"
ERROR:  to "/home/me/build-untitled3-Desktop_Qt_5_7_0_GCC_64bit-Debug/plugins/platforms/libqxcb.so"
ERROR: file copy failed from "/usr/lib/plugins/printsupport/libcupsprintersupport.so"
ERROR:  to "/home/me/build-untitled3-Desktop_Qt_5_7_0_GCC_64bit-Debug/plugins/printsupport/libcupsprintersupport.so"
Log: Created configuration file: "/home/me/build-untitled3-Desktop_Qt_5_7_0_GCC_64bit-Debug/qt.conf"

After running linuxdeployqt it looks like this

ldd /home/me/build-untitled3-Desktop_Qt_5_7_0_GCC_64bit-Debug/untitled3/home/me/build-untitled3-Desktop_Qt_5_7_0_GCC_64bit-Debug/untitled3: /home/me/build-untitled3-Desktop_Qt_5_7_0_GCC_64bit-Debug/lib/libQt5Core.so.5: version `Qt_5.7' not found (required by /home/me/build-untitled3-Desktop_Qt_5_7_0_GCC_64bit-Debug/untitled3)
/home/me/build-untitled3-Desktop_Qt_5_7_0_GCC_64bit-Debug/untitled3: /home/me/build-untitled3-Desktop_Qt_5_7_0_GCC_64bit-Debug/lib/libQt5Core.so.5: version `Qt_5' not found (required by /home/me/build-untitled3-Desktop_Qt_5_7_0_GCC_64bit-Debug/untitled3)
/home/me/build-untitled3-Desktop_Qt_5_7_0_GCC_64bit-Debug/untitled3: /home/me/build-untitled3-Desktop_Qt_5_7_0_GCC_64bit-Debug/lib/libQt5Widgets.so.5: version `Qt_5' not found (required by /home/me/build-untitled3-Desktop_Qt_5_7_0_GCC_64bit-Debug/untitled3)
    linux-vdso.so.1 =>  (0x00007ffd7effc000)
    libQt5Widgets.so.5 => /home/me/build-untitled3-Desktop_Qt_5_7_0_GCC_64bit-Debug/lib/libQt5Widgets.so.5 (0x00007f78b8681000)
    libQt5Core.so.5 => /home/me/build-untitled3-Desktop_Qt_5_7_0_GCC_64bit-Debug/lib/libQt5Core.so.5 (0x00007f78b8176000)
    libstdc++.so.6 => /home/me/build-untitled3-Desktop_Qt_5_7_0_GCC_64bit-Debug/lib/libstdc++.so.6 (0x00007f78b7db3000)

Which means that the wrong Qt libraries have been copied to the bundle location...

qmlimportscanner not found

I'm using the appimage build.

 ./linuxdeployqt  ~/dev/cool-retro-term/build/cool-retro-term -appimage -qmldir=~/dev/cool-retro-term/
"/tmp/.mount_9l9Smc/usr/bin:/home/salvo/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games"
app-binary: "/home/salvo/dev/cool-retro-term/build/cool-retro-term"
ERROR: FIXME: Here I would like to determine the original rpath of the main executable, but get: QSet("$ORIGIN/lib")
ERROR: qmlimportscanner not found at "/tmp/.mount_9l9Smc/qmlimportscanner"
ERROR: Rebuild qtdeclarative/tools/qmlimportscanner

FHS-like mode

linuxdeployqt should check whether the main executable is in a FHS-like structure, i.e., whether its parent directory is called bin/ and (possibly) whether there is a ../lib/ directory. If so, it should use those directories to deploy to rather than putting lib/ next to itself (which would result in a rather nonstandard bin/lib/).

no version information available

https://api.travis-ci.org/jobs/175388384/log.txt?deansi=true

$ ./dsremote 
./dsremote: ./dsremote: no version information available (required by ./dsremote)
./dsremote: ./dsremote: no version information available (required by ./dsremote)
./dsremote: ./dsremote: no version information available (required by ./dsremote)
./dsremote: ./dsremote: no version information available (required by ./dsremote)
./dsremote: ./dsremote: no version information available (required by ./dsremote)
./dsremote: ./dsremote: no version information available (required by ./dsremote)
./dsremote: ./dsremote: no version information available (required by ./dsremote)
./dsremote: ./dsremote: no version information available (required by ./dsremote)
./dsremote: ./dsremote: no version information available (required by ./dsremote)
./dsremote: ./dsremote: no version information available (required by ./dsremote)
./dsremote: ./dsremote: no version information available (required by ./dsremote)
./dsremote: ./dsremote: no version information available (required by ./dsremote)
./dsremote: ./dsremote: no version information available (required by ./dsremote)
./dsremote: ./dsremote: no version information available (required by ./dsremote)
./dsremote: ./dsremote: no version information available (required by ./dsremote)
./dsremote: ./dsremote: no version information available (required by ./dsremote)
./dsremote: relocation error: .dsremote: symbol , version  not defined in file  with link time reference

Possibly related to NixOS/patchelf#99?

Decide which libraries to bundle and which libraries not to bundle

We need to decide which libraries to bundle and which libraries not to bundle. Normally we will want to bundle things like libQt* but not bundle glibc*.

Currently this is done in a (too) simplistic way that also breaks on build systems that have no more /lib, e.g., Fedora:

    if (trimmed.startsWith("/lib"))
        return info;

Something more elaborated along the lines of a blacklist will be needed.

Do not deploy source code inside the bundle

For some strange reasons, QtCreator puts the source code files into the same directory as the compiled executable by default, e.g., to /home/me/build-untitled1-Desktop_Qt_5_7_0_GCC_64bit-Debug/.

Which means that if we bundle this directory, then the source code gets bundled, too - not what everyone wants. Not sure how to deal best with this.

kxmlgui .rc file not deployed

As described in chigraph/chigraph#16:

Because I am using KXmlGui, I need to be able to package the .rc file

Is not obvious to me where it should go.

https://techbase.kde.org/Development/Architecture/KDE4/XMLGUI_Technology#Lookup_of_.rc_files_.2F_versioning says

Usually, you supply a relative filename to KXMLGUIClient::setXML(). KDE looks for this file in a number of places (KXMLGUIClient::findMostRecentXMLFile), including in the user's home directory (see --kde4-config --path data), which is the first entry in the path. This means, ui-files can actually be overridden by the user (and among other things, this is used to save user settings such as customized toolbars or shortcuts.

References:

Test linuxdeployqt with real-life Qt applications

On a local machine built with Qt Creator AppImage

On Travis CI

  • linuxdeployqt itself

Focusing on projects that provide a .travis.yml and use Qt from ppa:beineri/opt-qt

Here is an idea: on Travis builds, consider to bundle everything that was installed in addition to what Travis provides out-of-the-box?

Other failure

$ ./linuxdeployqt  ~/dev/cool-retro-term/build/cool-retro-term -appimage
"/tmp/.mount_n6Y2pw/usr/bin:/home/salvo/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games"
app-binary: "/home/salvo/dev/cool-retro-term/build/cool-retro-term"
ERROR: FIXME: Here I would like to determine the original rpath of the main executable, but get: QSet("$ORIGIN/lib")

I tried without scanning for qml files (which I suspect will make a cool-retro-term that won't start), but that's what I get.

Deploying app built against pre-compiled Qt version not working (uses system/apt version)

Hi - thanks for this fantastic project

I've been trying to deploy an app that's dynamically linked to a Qt version (5.7) installed via the MaintenanceTool (from Qt Online Installer 2.0.3-2)

The system I'm building it on (Kubuntu 14.04) also happen to have an older version of Qt installed (Qt 5.2.1) via apt-get.

The application runs as expected outside the AppImage

The output from ldd on my executable correctly shows the path to the linked libQt5*.so files from the correct Qt 5.7 version

But the AppImage created by linuxdeployqt gives the following error after execution:

./dynappimg.AppImage: /tmp/.mount_l6DycG/lib/libQt5Qml.so.5: no version information available (required by ./dynappimg.AppImage)
./dynappimg.AppImage: /tmp/.mount_l6DycG/lib/libQt5Gui.so.5: no version information available (required by ./dynappimg.AppImage)
./dynappimg.AppImage: /tmp/.mount_l6DycG/lib/libQt5Quick.so.5: no version information available (required by ./dynappimg.AppImage)
./dynappimg.AppImage: /tmp/.mount_l6DycG/lib/libQt5Network.so.5: no version information available (required by ./dynappimg.AppImage)
./dynappimg.AppImage: /tmp/.mount_l6DycG/lib/libQt5Core.so.5: no version information available (required by ./dynappimg.AppImage)
./dynappimg.AppImage: /tmp/.mount_l6DycG/lib/libQt5Core.so.5: no version information available (required by ./dynappimg.AppImage)
./dynappimg.AppImage: relocation error: ./dynappimg.AppImage: symbol qt_version_tag, version Qt_5.7 not defined in file libQt5Core.so.5 with link time reference

After some guesswork I manually tried copying in the installed Qt 5.7 libraries to the generated AppDir/lib directory and ran AppImageAssistant again:

./dynappimg.AppImage: error while loading shared libraries: libicui18n.so.56: cannot open shared object file: No such file or directory

Copied more libs from the Qt5.7 installation to /lib which led me to:

This application failed to start because it could not find or load the Qt platform plugin "xcb"
in "".

Reinstalling the application may fix this problem.
Aborted (core dumped)

Copied in libqxcb.so to the platforms folder (this was empty in the AppDir?)

Finally I got around to:

QQmlApplicationEngine failed to load component
qrc:///main.qml:66 Type Core unavailable
qrc:///qml/Core.qml:4 plugin cannot be loaded for module "QtMultimedia": Cannot load library /tmp/.mount_ByHBdg/qml/QtMultimedia/libdeclarative_multimedia.so: (/tmp/.mount_ByHBdg/qml/QtMultimedia/libdeclarative_multimedia.so: symbol _ZTI23QDeclarativeVideoOutput, version Qt_5_PRIVATE_API not defined in file libQt5MultimediaQuick_p.so.5 with link time reference)

Did some more copying from the 5.7 install - and finally the AppImage ran.
I'm pasting the above snippets to let future googlers find this :)

Anyway it looks like linuxdeployqt can't handle, or at least, misinterpret the output from ldd when linked .so files is not the system / apt version?

I've tried passing various locations to linuxdeployqt -libpath parameter with no luck:

/path/to/Qt/5.7/gcc_64/

and

/path/to/Qt/5.7/gcc_64/lib/

I'll be glad to provide some more info if need be

Remove the need for AppRun symlink

Currently we are creating an AppRun symlink that is needed for linuxdeployqt to find its main executable. Effectively this turns the bundled app directory into an AppDir.

While having an AppRun file might be desirable in many cases (e.g., when generating an AppImage), there might be cases where this link is not wanted; hence linuxdeployqt code should be changed to make this optional.

Make it work with Qt4 apps

In deployPlugins we have hardcoded names such as libQt5Gui.

At the very least, this should be turned into libQt*Gui in containsHowOften() but it also needs to be tested with Qt 3 and/or 4 applications.

linuxdeployqt could not locate libqxcb.so

linuxdeployqt could not locate a plugin. The file is at /usr/lib/x86_64-linux-gnu/qt5/plugins/platforms/libqxcb.so. Below is an excerpt from the log file:

I cloned today and compiled.

Command:

linuxdeployqt encryptpad -bundle-non-qt-libs -verbose=3
Log: Deploying plugins from "/usr/lib/plugins"
Log: deploymentInfo.deployedLibraries before attempting to bundle required plugins: ("libbotan-1.10.so.1", "libQt5Widgets.so.5", "libQt5Gui.so.5", "libQt5Core.so.5", "libbz2.so.1.0", "libcrypto.so.1.0.0", "libgmp.so.10", "libpng12.so.0", "libharfbuzz.so.0", "libicui18n.so.55", "libicuuc.so.55", "libpcre16.so.3", "libffi.so.6", "libfreetype.so.6", "libgraphite2.so.3", "libglapi.so.0", "libXext.so.6", "libXdamage.so.1", "libXfixes.so.3", "libX11-xcb.so.1", "libxcb-glx.so.0", "libxcb-dri2.so.0", "libxcb-dri3.so.0", "libxcb-present.so.0", "libxcb-sync.so.1", "libxshmfence.so.1", "libXxf86vm.so.1", "libicudata.so.55", "libXau.so.6", "libXdmcp.so.6")
Log: libQt5Gui detected
Log: pluginList after having detected hopefully all required plugins: ("platforms/libqxcb.so")
ERROR: file copy failed from "/usr/lib/plugins/platforms/libqxcb.so"
ERROR:  to "./plugins/platforms/libqxcb.so"
Log: Created configuration file: "./qt.conf"

Environment:

$ qmake --version
QMake version 3.0
Using Qt version 5.4.2 in /usr/lib/x86_64-linux-gnu

Add knowledge about KF5 plugins

Like Qt libraries, KF5 libraries can require certain plugins to be installed. The knowledge about these could be added to this tool.

Ideas how to get this information:

  1. Generate a graph about KF5 package dependencies from debian packaing information, and deduce what needs what from there
  2. grep for the names of directories beneath plugins in a full-blown KF5 installation

Example for 2.:

ls /tmp/.mount_OQ5hgR/usr/lib/qt5/plugins/kf5/ shows, among others, 
kf5/kio which I will investigate here.

grep -r "kf5/kio" /tmp/.mount_OQ5hgR/usr/lib/ 
Binary file /tmp/.mount_OQ5hgR/usr/lib/libKF5KIOCore.so.5.25.0 matches
Binary file /tmp/.mount_OQ5hgR/usr/lib/libKF5KIOWidgets.so.5.25.0 matches
Binary file /tmp/.mount_OQ5hgR/usr/lib/libexec/kf5/kiod5 matches
Binary file /tmp/.mount_OQ5hgR/usr/lib/libkdeinit5_klauncher.so matches
Binary file /tmp/.mount_OQ5hgR/usr/lib/qt5/plugins/kcm_kio.so matches
Binary file /tmp/.mount_OQ5hgR/usr/lib/qt5/plugins/kcm_trash.so matches
Binary file /tmp/.mount_OQ5hgR/usr/lib/qt5/plugins/kf5/kio/file.so matches
Binary file /tmp/.mount_OQ5hgR/usr/lib/qt5/plugins/kf5/kio/ftp.so matches
Binary file /tmp/.mount_OQ5hgR/usr/lib/qt5/plugins/kf5/kio/http.so matches
Binary file /tmp/.mount_OQ5hgR/usr/lib/qt5/plugins/kf5/kio/trash.so matches

I would deduce from that that whenever libKF5KIOCore and/or libKF5KIOWidgets is going to be bundled, then the kf5/kio plugins should be bundled as well, and possibly also libexec/kf5/kiod5 and libkdeinit5_klauncher.so.

QtWebEngineProcess error

I applied linuxdeployqt to a custom build of otter-browser. The AppImage is sucessfully built, but when I run it on another sytem, it fails with the message "QXcbIntegration: Cannot create platform OpenGL context, neither GLX nor EGL are enabled".

I first used linuxdeployqt-1-x86_64.AppImage, then I used the latest linuxdeployqt from git, with the latest AppImageAssistant. In this case, the image failed with the message "Could not find QtWebEngineProcess".
Here are the libraries that are not packaged by the AppImage when I use linuxdeployqt otter-browser -libpath=/home/vagrant/Qt/5.7/gcc_64/lib -verbose=2 -appimage -bundle-non-qt-libs:

% ldd otter-browser | grep -v otter-browser/tmp | sort
    /lib64/ld-linux-x86-64.so.2 (0x000055b44386b000)
    libasound.so.2 => /usr/lib/x86_64-linux-gnu/libasound.so.2 (0x00007f6e545cb000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f6e57af3000)
    libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f6e56cdb000)
    libexpat.so.1 => /lib/x86_64-linux-gnu/libexpat.so.1 (0x00007f6e4e4eb000)
    libffi.so.6 => /usr/lib/x86_64-linux-gnu/libffi.so.6 (0x00007f6e4eda3000)
    libfontconfig.so.1 => /usr/lib/x86_64-linux-gnu/libfontconfig.so.1 (0x00007f6e55b33000)
    libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f6e57e93000)
    libglib-2.0.so.0 => /lib/x86_64-linux-gnu/libglib-2.0.so.0 (0x00007f6e5676b000)
    libGL.so.1 => /usr/lib/x86_64-linux-gnu/libGL.so.1 (0x00007f6e57593000)
    libgobject-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 (0x00007f6e56a83000)
    libgpg-error.so.0 => /lib/x86_64-linux-gnu/libgpg-error.so.0 (0x00007f6e4b943000)
    libICE.so.6 => /usr/lib/x86_64-linux-gnu/libICE.so.6 (0x00007f6e4da43000)
    libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f6e580ab000)
    libnvidia-glcore.so.367.44 => /usr/lib/x86_64-linux-gnu/libnvidia-glcore.so.367.44 (0x00007f6e4f64b000)
    libnvidia-tls.so.367.44 => /usr/lib/x86_64-linux-gnu/tls/libnvidia-tls.so.367.44 (0x00007f6e5138b000)
    libpcre.so.3 => /lib/x86_64-linux-gnu/libpcre.so.3 (0x00007f6e4eb2b000)
    libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f6e578d3000)
    libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 (0x00007f6e4c26b000)
    librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f6e5713b000)
    libSM.so.6 => /usr/lib/x86_64-linux-gnu/libSM.so.6 (0x00007f6e4d83b000)
    libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f6e583b3000)
    libuuid.so.1 => /lib/x86_64-linux-gnu/libuuid.so.1 (0x00007f6e4c76b000)
    libX11.so.6 => /usr/lib/x86_64-linux-gnu/libX11.so.6 (0x00007f6e5553b000)
    libXau.so.6 => /usr/lib/x86_64-linux-gnu/libXau.so.6 (0x00007f6e4cb7b000)
    libxcb.so.1 => /usr/lib/x86_64-linux-gnu/libxcb.so.1 (0x00007f6e4e093000)
    libXdmcp.so.6 => /usr/lib/x86_64-linux-gnu/libXdmcp.so.6 (0x00007f6e4c973000)
    libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f6e539db000)
    linux-vdso.so.1 (0x00007ffd7d3c5000)

Here are the libraries load from the AppImage:

libasyncns.so.0
libattr.so.1
libcap.so.2
libdbus-1.so.3
libFLAC.so.8
libfreetype.so.6
libgcrypt.so.20
libgthread-2.0.so.0
libhunspell-1.3.so.0
libicudata.so.56
libicui18n.so.56
libicuuc.so.56
libjson-c.so.2
liblzma.so.5
libnsl.so.1
libnspr4.so
libnss3.so
libnssutil3.so
libogg.so.0
libplc4.so
libplds4.so
libpng12.so.0
libpulsecommon-5.0.so
libpulse.so.0
libQt5Core.so.5
libQt5DBus.so.5
libQt5Gui.so.5
libQt5Multimedia.so.5
libQt5Network.so.5
libQt5PrintSupport.so.5
libQt5Qml.so.5
libQt5Quick.so.5
libQt5WebChannel.so.5
libQt5WebEngineCore.so.5
libQt5WebEngineWidgets.so.5
libQt5Widgets.so.5
libQt5XmlPatterns.so.5
libsmime3.so
libsndfile.so.1
libsystemd.so.0
libvorbisenc.so.2
libvorbis.so.0
libwrap.so.0
libX11-xcb.so.1
libXcomposite.so.1
libXcursor.so.1
libXdamage.so.1
libXext.so.6
libXfixes.so.3
libXi.so.6
libxml2.so.2
libXrender.so.1
libxslt.so.1
libXtst.so.6

As a side note, when there is no .desktop file, the command linuxdeployqt silently fails with an apparent success.

Another surprise was that the resulting file was named ..AppImage which is a very uncommon and hidden name. I suspect the intended name was ../AppImage.

Allow Qt from the distro to be deployed?

Right now we only deploy Qt if it does not come from the distro (i.e., lives outside of /usr or /lib).

Should we allow Qt from the distro to be deployed?

In this case, we could detect libQt* or something from the Qt plugin path is a candidate to be bundled, and allow that; regardless of what we do with system libraries otherwise. The risk of this is that distribution-provided Qt might have distribution-specific patches and/or dependencies (e.g., Ubuntu global menu?) which are unknown how they perform on other distributions.

Dependencies of plugins do not get bundled

And then it falls back to seaching the one from the system, which can lead to unexpected results, e.g.,

/home/me/build-untitled3-Desktop_Qt_5_7_0_GCC_64bit-Debug/plugins/platforms/libqxcb.so: /usr/lib/x86_64-linux-gnu/libQt5XcbQpa.so.5: version `Qt_5_PRIVATE_API' not found (required by /home/me/build-untitled3-Desktop_Qt_5_7_0_GCC_64bit-Debug/plugins/platforms/libqxcb.so)

When manually copying this in, then I can launch the app on another system...

Remove references and extra code regarding "Frameworks"

"Frameworks" are a concept from macOS that doesn't exist on Linux. When converting over from macdeployqt I tried changing some of the code to look for .so* files rather than for frameworks; but there are still instances in the code that are not handled correctly.

Find libaries in non-standard places by considering the original RPATH (e.g., libpulsecommon-9.0.so)

One of my binary’s dependencies is libpulsecommon-9.0.so. ldd outputs correctly:

libpulsecommon-9.0.so => /usr/lib/pulseaudio/libpulsecommon-9.0.so (0x00007f10a344b000)

When I run linuxdeployqt the first time, libpulsecommon-9.0.so is present in the newly created /lib folder. These are the relevant log outputs:

[…]
ERROR: ldd outputLine: "\tlibpulsecommon-9.0.so => not found"
[…]
Log:  copied: "/usr/lib/pulseaudio/libpulsecommon-9.0.so"
Log:  to "./lib//libpulsecommon-9.0.so"
[…]

But for another reason I ran linuxdeployqt twice, the second time libpulsecommon-9.0.so is missing and the output now reads:

[…]
Log: Deploying libraries found inside: ("./AppRun", "./lib/libQt5Python27.so", "./lib/libpulsecommon-9.0.so", "./lib/libQt5Python27_QtAll.so", "./lib/libQt5Xml.so.5", "./lib/libXrender.so.1", "./lib/libXau.so.6", "./lib/libpcre16.so.0", "./lib/libQt5Quick.so.5", "./lib/libgstreamer-1.0.so.0", "./lib/libsqlite3.so.0", "./lib/libglapi.so.0", "./lib/libffi.so.6", "./lib/libvorbis.so.0", "./lib/libgraphite2.so.3", "./lib/libgstapp-1.0.so.0", "./lib/libQt5OpenGL.so.5", "./lib/libsndfile.so.1", "./lib/libQt5Widgets.so.5", "./lib/libwebp.so.6", "./lib/libQt5PrintSupport.so.5", "./lib/libxcb-glx.so.0", "./lib/libsnappy.so.1", "./lib/libcap.so.2", "./lib/libjson-c.so.2", "./lib/libQt5Qml.so.5", "./lib/libQt5Sensors.so.5", "./lib/libutil.so.1", "./lib/libQt5XmlPatterns.so.5", "./lib/libQt5Help.so.5", "./lib/libharfbuzz.so.0", "./lib/libsystemd.so.0", "./lib/libQt5Gui.so.5", "./lib/libxml2.so.2", "./lib/libxcb-sync.so.1", "./lib/libicudata.so.57", "./lib/libQt5MultimediaWidgets.so.5", "./lib/libpulse.so.0", "./lib/libXdmcp.so.6", "./lib/libgcrypt.so.20", "./lib/libXdamage.so.1", "./lib/libquazip5.so.1", "./lib/libQt5Network.so.5", "./lib/libXfixes.so.3", "./lib/libXext.so.6", "./lib/libjpeg.so.8", "./lib/libQt5Svg.so.5", "./lib/libcrypto.so.1.0.0", "./lib/libQt5Python27.so", "./lib/libasyncns.so.0", "./lib/liborc-0.4.so.0", "./lib/libproxy.so.1", "./lib/libgsttag-1.0.so.0", "./lib/libbz2.so.1.0", "./lib/libgmodule-2.0.so.0", "./lib/libQt5Concurrent.so.5", "./lib/libQt5Multimedia.so.5", "./lib/libogg.so.0", "./lib/liblz4.so.1", "./lib/libgstbase-1.0.so.0", "./lib/libFLAC.so.8", "./lib/libpulsecommon-9.0.so", "./lib/libQt5Sql.so.5", "./lib/libgstvideo-1.0.so.0", "./lib/libxcb-dri3.so.0", "./lib/libX11-xcb.so.1", "./lib/libicuuc.so.57", "./lib/libgstpbutils-1.0.so.0", "./lib/libdbus-1.so.3", "./lib/libGLU.so.1", "./lib/libQt5Python27_QtAll.so", "./lib/libQt5CLucene.so.5", "./lib/libXcomposite.so.1", "./lib/libxcb-present.so.0", "./lib/libpython2.7.so.1.0", "./lib/libQt5WebChannel.so.5", "./lib/libxcb-dri2.so.0", "./lib/libXxf86vm.so.1", "./lib/libvorbisenc.so.2", "./lib/libxshmfence.so.1", "./lib/libQt5WebKitWidgets.so.5", "./lib/libfreetype.so.6", "./lib/libicui18n.so.57", "./lib/libpng16.so.16", "./lib/liblzma.so.5", "./lib/libQt5WebKit.so.5", "./lib/libQt5Positioning.so.5", "./lib/libssl.so.1.0.0", "./lib/libQt5Core.so.5", "./lib/libgstaudio-1.0.so.0", "./lib/libxslt.so.1")
[…]
ERROR: findDependencyInfo: ""
[…]
Log:  copied: "/usr/lib/pulseaudio/libpulsecommon-9.0.so"
Log:  to "./lib//libpulsecommon-9.0.so"
[…]
ERROR: file copy failed from "/path/to/linuxdeployqt_test/./lib/libpulsecommon-9.0.so"
ERROR:  to "./lib//libpulsecommon-9.0.so"
[…]

I noticed that libpulsecommon-9.0.so appears twice in the list of libraries found in ./AppRun.

Does not bundle (Ubuntu) system Qt plugins properly

(Ubuntu) system Qt has a slightly different directory structure than the Qt binaries downloaded from the Qt Company.

Log: pluginList after having detected hopefully all required plugins: ("platforms/libqxcb.so")
ERROR: file copy failed from "/usr/lib/plugins/platforms/libqxcb.so"
ERROR:  to "./plugins/platforms/libqxcb.so"

Workaround:

sudo ln -s /usr/lib/x86_64-linux-gnu/qt5/plugins /usr/lib/plugins

Other workaround: Use non-system Qt, e.g., from https://launchpad.net/~beineri

Optionally provide a sysroot image to compile against

When you build an app on a newer version of a Linux distribution than the systems you are targeting, then your bundle will fail to run on the target systems (unless you decide to bundle every single dependency down to glibc and possibly even the ld loader).

An alternative is to compile on a "reasonably old" system.

Or, as another alternative, we might be able to provide an image to (cross-)compile against like outlined here:

The way I would approach this is grab your oldmachine:/usr/lib and oldmachine:/usr/include so you have e.g. newmachine:/oldmachinecompiler/usr/{lib|include} then build a cross compiler setting --sysroot to newmachine:/oldmachinecompiler/
This is really the only way to ensure that any library requirements (including libc) in your program are compatible with oldmachine.

This would have the advantage that we could use newer build tools such as compilers on the build system and still be able to compile against an older version of the "Linux Platform".

Looks like the idea is not as crazy as it sounds, as Chromium seems to be doing exactly that:

The chromium build system for Linux will (by default) use a sysroot image rather than building against the libraries installed on the host system. This serves several purposes. Firstly, it ensures that binaries will run on all supported linux systems independent of the packages installed on the build machine. Secondly, it makes the build more hermetic, preventing issues that arise for variations among developers' systems.
The sysroot consists of a minimal installation of Debian/stable (or old-stable) to ensure maximum compatibility. Pre-built sysroot images are stored in Google Cloud Storage and downloaded during gclient runhooks

https://chromium.googlesource.com/chromium/src/+/master/docs/linux_sysroot.md

And Electron too:
https://github.com/electron/debian-sysroot-image-creator/releases

libsoftokn3.so issue

When I try to use -bundle-non-qt-libs on a working Otter AppDir or try to convert it to an AppImage, Otter fails to run with

[1022/144633:ERROR:nss_util.cc(740)] Error initializing NSS with a persistent database (sql:/home/me/.pki/nssdb): libsoftokn3.so: cannot open shared object file: No such file or directory
[1022/144633:ERROR:nss_util.cc(211)] Error initializing NSS without a persistent database: NSS error code: -5925
[1022/144633:FATAL:nss_util.cc(213)] nss_error=-5925, os_error=0

The reason for this is to be investigated.

When I delete libnss3.so from the AppDir, then it starts working again.

Optionally bundle a) more and/or b) everything

The case for bundling more

Right now it is expected that non-standard libraries must be taken care of by the developer manually.
This is because currently we do not bundle anything from the system, i.e., /usr or /lib.

One way around this would be to (optionally) bundle (certain) libraries from /usr.

The case for bundling everything

Right now the bundles generated by linuxdeployqt are expected to run on systems no older than the build systems that were used to compile both the application and libraries (e.g., Qt).

This is because currently we do not bundle low-level system libraries such as glibc (which also would probably need that we ship a corresponding loader).

One way around this would be to (optionally) bundle every dependency (down to glibc and the ld loader). This is not generally recommended since it adds unnecessary overhead in cases where compiling on an older build system is an option.

However, there might be some edge cases where building on an older build system is simply not possible; for those cases, we could have an option to bundle everything.

To implement this, we could use something like patchelf --set-interpreter to use our private bundled interpreter matching the bundled glibc version, or http://bitwagon.com/rtldi/rtldi.html.

Please leave a comment here if you are interested in such a feature and state your use case. I will only consider this if there is legitimate demand for it (as opposed to developer sloppiness).

Prevent Qt from loading plugins from 'unexpected' places

windeployqt does the following:

Patch the preconfigured Qt path in Qt5Core to '.'. This allows one to immediately test whether the generated package is self-contained, without Qt being able to 'fall back' to the installed Qt for loading plugins. It is also fixing a potential security issue where Qt tries to load plugins
from 'unexpected' places. The effect is the same as adding a qt.conf file with all the defaults. However, a lot of people consider adding a qt.conf ugly.

https://github.com/RSATom/Qt/blob/master/qttools/src/windeployqt/utils.cpp#L924-L971
https://codereview.qt-project.org/#/c/121731/

Maybe linuxdeployqt should do that too.

Qt files are not bundled without -bundle-non-qt-libs

When running linuxdeployqt encryptpad, Qt files are missing from the build directory.

./lib
./lib/libicudata.so.55
./lib/libicui18n.so.55
./lib/libicuuc.so.55
./AppRun
./encryptpad

If I use -bundle-non-qt-libs, linuxdeployqt copies more files including the Qt files.

Environment:

$ qmake --version
QMake version 3.0
Using Qt version 5.4.2 in /usr/lib/x86_64-linux-gnu

Run ldd on Qt plugins as well

First, thanks for this tool. I have managed to use it on a rather big Qt5 application (one app, 73 loadable plugins, 25 shared libraries), and it worked (though I have not yet tried the AppImage feature). To make it work, I have listed all the loadable plugins with extra -executable= options. Yet I had to use a workaround for one thing, and that is what this issue report is about...

When one uses the option -bundle-non-qt-libs, the lib dependencies (but the core ones listed in the exclude ist) are bundled. That allows to create a portable bundle of the application (which is the purpose of linuxdeployqt). But it seems that the dependencies of the Qt plugins are not checked. In my case, I compiled the application on CentOS 6, with Qt5 from the official EPEL RPM repository. The libqxcb.so Qt plugin NEEDs libudev.so.0, but that library is not bundled. I had to copy it manually, to be able to run the bundled application on another Linux version (Fedora 24). Probably the ldd tool is not used on Qt plugins, and that would explain the bug.

vlc libraries not binding

Vlc libraries(libvlc or vlc) are not binding to the appimage eventhough I used -bundle-non-qt-libs.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.