Open cvuchener opened 6 years ago
No, this seems like a bug on our end. Could you provide the output of ldd[tree] usr/bin/DwarfTherapist
, please?
lddtree output:
DwarfTherapist => usr/bin/DwarfTherapist (interpreter => /lib64/ld-linux-x86-64.so.2)
libQt5Widgets.so.5 => /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0
libgobject-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
libffi.so.6 => /usr/lib/x86_64-linux-gnu/libffi.so.6
libglib-2.0.so.0 => /lib/x86_64-linux-gnu/libglib-2.0.so.0
libpcre.so.3 => /lib/x86_64-linux-gnu/libpcre.so.3
libX11.so.6 => /usr/lib/x86_64-linux-gnu/libX11.so.6
libxcb.so.1 => /usr/lib/x86_64-linux-gnu/libxcb.so.1
libXau.so.6 => /usr/lib/x86_64-linux-gnu/libXau.so.6
libXdmcp.so.6 => /usr/lib/x86_64-linux-gnu/libXdmcp.so.6
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2
libQt5Qml.so.5 => /usr/lib/x86_64-linux-gnu/libQt5Qml.so.5
libQt5Gui.so.5 => /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5
libpng12.so.0 => /lib/x86_64-linux-gnu/libpng12.so.0
libharfbuzz.so.0 => /usr/lib/x86_64-linux-gnu/libharfbuzz.so.0
libfreetype.so.6 => /usr/lib/x86_64-linux-gnu/libfreetype.so.6
libgraphite2.so.3 => /usr/lib/x86_64-linux-gnu/libgraphite2.so.3
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1
libGL.so.1 => /var/lib/VBoxGuestAdditions/lib/libGL.so.1
VBoxOGLcrutil.so => /usr/lib/x86_64-linux-gnu/VBoxOGLcrutil.so
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1
libXcomposite.so.1 => /usr/lib/x86_64-linux-gnu/libXcomposite.so.1
libXdamage.so.1 => /usr/lib/x86_64-linux-gnu/libXdamage.so.1
libXfixes.so.3 => /usr/lib/x86_64-linux-gnu/libXfixes.so.3
libXext.so.6 => /usr/lib/x86_64-linux-gnu/libXext.so.6
libQt5Network.so.5 => /usr/lib/x86_64-linux-gnu/libQt5Network.so.5
libQt5Core.so.5 => /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
libicui18n.so.52 => /usr/lib/x86_64-linux-gnu/libicui18n.so.52
libicuuc.so.52 => /usr/lib/x86_64-linux-gnu/libicuuc.so.52
libicudata.so.52 => /usr/lib/x86_64-linux-gnu/libicudata.so.52
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6
As a workaround, you may be able to use something along the lines of
mkdir -p appdir/usr/optional/ ; wget -c https://github.com/darealshinji/AppImageKit-checkrt/releases/download/continuous/exec-x86_64.so -O ./appdir/usr/optional/exec.so
mkdir -p appdir/usr/optional/libstdc++/ ; cp /usr/lib/x86_64-linux-gnu/libstdc++.so.6 ./appdir/usr/optional/libstdc++/
( cd appdir ; rm AppRun ; wget -c https://github.com/darealshinji/AppImageKit-checkrt/releases/download/continuous/AppRun-patched-x86_64 -O AppRun ; chmod a+x AppRun)
...
# Manually invoke appimagetool so that libstdc++ gets bundled and the modified AppRun stays intact
./linuxdeployqt*.AppImage --appimage-extract
export PATH=$(readlink -f ./squashfs-root/usr/bin):$PATH
./squashfs-root/usr/bin/appimagetool -g ./appdir/ $NAME-$VERSION-x86_64.AppImage
This is what I am using for https://github.com/probonopd/audacity/blob/AppImage/.travis.yml and it seems to be working for me.
I am experimenting with AppImageKit-checkrt in a Ubuntu 14.04 VM (VirtualBox). I used to use the
-appimage
option to create a appimage directly, but now, I need to include the AppRun, exec.so and libs before creating the appimage, so I removed the option. And linuxdeployqt is no longer copying the Qt libs.Here is the structure of my appdir, before running linuxdeployqt (the content of share/dwarftherapist is omitted to keep it short):
When I run linuxdeployqt, only 4 libs are copied: libGL.so.1, libicudata.so.52, libicui18n.so.52, libicuuc.so.52 (libGL.so is part of the video driver, I am not sure it should be copied).
-verbose=3
log is very long, but I can provide it if it is needed.Adding
-bundle-non-qt-libs
(log here), bundles the Qt libs (and others, including another part of the video driver):Am I misunderstanding the meaning of
-bundle-non-qt-libs
or is something wrong here?