2020-11-27 13:49

AppImage compatible with Ubuntu 16.04+ only

While 0.1.26-alpha works for me, any more recent AppImage including 0.2.0-beta crashes with ./CubicSDR.AppImage: symbol lookup error: ./CubicSDR.AppImage: undefined symbol: gdk_mir_display_get_type.

Im running Debian stretch (testing) and as Mir is Ubuntu specific stuff there's obviously no Mir backend in my GDK libraries, however, as the AppImage is advertised to be self-contained I would not expect my GDK libraries to make a difference.

It does not look that self-contained at all:

% ldd CubicSDR.AppImage 
    linux-vdso.so.1 (0x00007ffd3ed10000)
    libfuse.so.2 => /lib/x86_64-linux-gnu/libfuse.so.2 (0x00007f9e23f52000)
    libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f9e23d35000)
    libglib-2.0.so.0 => /lib/x86_64-linux-gnu/libglib-2.0.so.0 (0x00007f9e23a23000)
    libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f9e23808000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f9e23464000)
    libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f9e2325f000)
    /lib64/ld-linux-x86-64.so.2 (0x000055f188f0a000)
    libpcre.so.3 => /lib/x86_64-linux-gnu/libpcre.so.3 (0x00007f9e22fef000)


  • 点赞
  • 写回答
  • 关注问题
  • 收藏
  • 复制链接分享
  • 邀请回答


  • weixin_39775976 weixin_39775976 5月前

    Thanks let me know if you are running into any issues.

    点赞 评论 复制链接分享
  • weixin_39601657 weixin_39601657 5月前

    I've worked up a better build process based on 's suggestions and it's now available to try on the rc4 release page when you have a chance:


    Apologies for the hacked up builds from earlier which caused confusion and gave a bad impression of AppImageKit -- didn't read the docs well enough to understand the process before assuming I had a working build..

    If all is good I'll maintain and use the https://github.com/cjcliffe/CubicSDR-AppImageKit repository for all release builds.

    I think I'll keep the AppImage as the standard Linux "download and run" bundle and also migrate the flatpak release to it's own style of repository -- distributing the .flatpak bundle isn't really the recommended way to use it.

    点赞 评论 复制链接分享
  • weixin_39601657 weixin_39601657 5月前

    Working great here even with a few Live CD images I downloaded; going to close this one up and any related issues can probably go to the CubicSDR-AppImageKit repository now.

    Thanks for the help and persistence! :)

    点赞 评论 复制链接分享
  • weixin_39733146 weixin_39733146 5月前

    : Works fine. :+1:

    : Mir won't run X apps itself, but there's XMir. I guess a version built without Mir support works with XMir as well, so it would probably work on that new Ubuntu flavor, right.

    点赞 评论 复制链接分享
  • weixin_39601657 weixin_39601657 5月前

    Hmm; those appear to be dependencies of the AppImage binary itself? Perhaps building on something other than Ubuntu15 would yield better results..

    点赞 评论 复制链接分享
  • weixin_39733146 weixin_39733146 5月前

    I agree. Googling around a bit reveals those same dependencies for any AppImage. They look pretty basic anyway, except for glib (and fuse (and pcre)), but it in fact looks like that's a requirement for AppImages. So much for the self-contained promise of that mechanism...

    Back to the actual issue: If I inspect the AppImage I see a lot of dynamically linked libraries, but only hamlib, liquid, and SoapySDR are included.

    cschramm ~ % sudo mount -o loop CubicSDR.AppImage /mnt
    mount: /dev/loop0 is write-protected, mounting read-only
    cschramm ~ % ldd /mnt/usr/bin/CubicSDR
        linux-vdso.so.1 (0x00007ffe12900000)
        libhamlib.so.2 => /usr/lib/libhamlib.so.2 (0x00007f52764ff000)
        libliquid.so => not found
        libGL.so.1 => /usr/lib/x86_64-linux-gnu/libGL.so.1 (0x00007f527628d000)
        libgtk-3.so.0 => /usr/lib/x86_64-linux-gnu/libgtk-3.so.0 (0x00007f52759a7000)
        libgdk-3.so.0 => /usr/lib/x86_64-linux-gnu/libgdk-3.so.0
        libpangocairo-1.0.so.0 => /usr/lib/x86_64-linux-gnu/libpangocairo-1.0.so.0 (0x00007f5275799000)
        libpango-1.0.so.0 => /usr/lib/x86_64-linux-gnu/libpango-1.0.so.0 (0x00007f527554d000)
        libcairo.so.2 => /usr/lib/x86_64-linux-gnu/libcairo.so.2 (0x00007f5275239000)
        libgdk_pixbuf-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgdk_pixbuf-2.0.so.0 (0x00007f5275016000)
        libgobject-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 (0x00007f5274dc3000)
        libglib-2.0.so.0 => /lib/x86_64-linux-gnu/libglib-2.0.so.0 (0x00007f5274ab2000)
        libX11.so.6 => /usr/lib/x86_64-linux-gnu/libX11.so.6 (0x00007f527476e000)
        libXxf86vm.so.1 => /usr/lib/x86_64-linux-gnu/libXxf86vm.so.1 (0x00007f5274568000)
        libSM.so.6 => /usr/lib/x86_64-linux-gnu/libSM.so.6 (0x00007f5274360000)
        libpng12.so.0 => /lib/x86_64-linux-gnu/libpng12.so.0 (0x00007f5274139000)
        libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f5273f35000)
        libSoapySDR.so.0.5-1 => not found
        libpulse-simple.so.0 => /usr/lib/x86_64-linux-gnu/libpulse-simple.so.0 (0x00007f5273d2f000)
        libpulse.so.0 => /usr/lib/x86_64-linux-gnu/libpulse.so.0 (0x00007f5273ade000)
        libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f52737e0000)
        libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f527345f000)
        libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f5273249000)
        libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f527302c000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f5272c87000)
        libusb-0.1.so.4 => /lib/x86_64-linux-gnu/libusb-0.1.so.4 (0x00007f5272a7e000)
        libexpat.so.1 => /lib/x86_64-linux-gnu/libexpat.so.1 (0x00007f5272855000)
        libxcb-dri3.so.0 => /usr/lib/x86_64-linux-gnu/libxcb-dri3.so.0 (0x00007f5272651000)
        libxcb-present.so.0 => /usr/lib/x86_64-linux-gnu/libxcb-present.so.0 (0x00007f527244e000)
        libxcb-randr.so.0 => /usr/lib/x86_64-linux-gnu/libxcb-randr.so.0 (0x00007f5272240000)
        libxcb-xfixes.so.0 => /usr/lib/x86_64-linux-gnu/libxcb-xfixes.so.0 (0x00007f5272037000)
        libxcb-render.so.0 => /usr/lib/x86_64-linux-gnu/libxcb-render.so.0 (0x00007f5271e2d000)
        libxcb-shape.so.0 => /usr/lib/x86_64-linux-gnu/libxcb-shape.so.0 (0x00007f5271c29000)
        libxcb-sync.so.1 => /usr/lib/x86_64-linux-gnu/libxcb-sync.so.1 (0x00007f5271a21000)
        libxshmfence.so.1 => /usr/lib/x86_64-linux-gnu/libxshmfence.so.1 (0x00007f527181e000)
        libglapi.so.0 => /usr/lib/x86_64-linux-gnu/libglapi.so.0 (0x00007f52715f0000)
        libXext.so.6 => /usr/lib/x86_64-linux-gnu/libXext.so.6 (0x00007f52713dd000)
        libXdamage.so.1 => /usr/lib/x86_64-linux-gnu/libXdamage.so.1 (0x00007f52711da000)
        libXfixes.so.3 => /usr/lib/x86_64-linux-gnu/libXfixes.so.3 (0x00007f5270fd4000)
        libX11-xcb.so.1 => /usr/lib/x86_64-linux-gnu/libX11-xcb.so.1 (0x00007f5270dd1000)
        libxcb-glx.so.0 => /usr/lib/x86_64-linux-gnu/libxcb-glx.so.0 (0x00007f5270bb8000)
        libxcb-dri2.so.0 => /usr/lib/x86_64-linux-gnu/libxcb-dri2.so.0 (0x00007f52709b3000)
        libxcb.so.1 => /usr/lib/x86_64-linux-gnu/libxcb.so.1 (0x00007f5270790000)
        libdrm.so.2 => /usr/lib/x86_64-linux-gnu/libdrm.so.2 (0x00007f5270581000)
        libgdk-3.so.0 => not found
        libgmodule-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgmodule-2.0.so.0 (0x00007f527037c000)
        libXi.so.6 => /usr/lib/x86_64-linux-gnu/libXi.so.6 (0x00007f527016c000)
        libXcomposite.so.1 => /usr/lib/x86_64-linux-gnu/libXcomposite.so.1 (0x00007f526ff69000)
        libcairo-gobject.so.2 => /usr/lib/x86_64-linux-gnu/libcairo-gobject.so.2 (0x00007f526fd5f000)
        libatk-1.0.so.0 => /usr/lib/x86_64-linux-gnu/libatk-1.0.so.0 (0x00007f526fb39000)
        libatk-bridge-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libatk-bridge-2.0.so.0 (0x00007f526f90a000)
        libxkbcommon.so.0 => /usr/lib/x86_64-linux-gnu/libxkbcommon.so.0 (0x00007f526f6c9000)
        libwayland-cursor.so.0 => /usr/lib/x86_64-linux-gnu/libwayland-cursor.so.0 (0x00007f526f4c1000)
        libwayland-egl.so.1 => /usr/lib/x86_64-linux-gnu/libwayland-egl.so.1 (0x00007f526f2bf000)
        libwayland-client.so.0 => /usr/lib/x86_64-linux-gnu/libwayland-client.so.0 (0x00007f526f0af000)
        libepoxy.so.0 => /usr/lib/x86_64-linux-gnu/libepoxy.so.0 (0x00007f526edbb000)
        libpangoft2-1.0.so.0 => /usr/lib/x86_64-linux-gnu/libpangoft2-1.0.so.0 (0x00007f526eba5000)
        libfontconfig.so.1 => /usr/lib/x86_64-linux-gnu/libfontconfig.so.1 (0x00007f526e966000)
        libfreetype.so.6 => /usr/lib/x86_64-linux-gnu/libfreetype.so.6 (0x00007f526e6b7000)
        libgio-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0 (0x00007f526e32f000)
        libgthread-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgthread-2.0.so.0 (0x00007f526e12c000)
        libthai.so.0 => /usr/lib/x86_64-linux-gnu/libthai.so.0 (0x00007f526df23000)
        libpixman-1.so.0 => /usr/lib/x86_64-linux-gnu/libpixman-1.so.0 (0x00007f526dc7a000)
        libpng16.so.16 => /usr/lib/x86_64-linux-gnu/libpng16.so.16 (0x00007f526da48000)
        libxcb-shm.so.0 => /usr/lib/x86_64-linux-gnu/libxcb-shm.so.0 (0x00007f526d844000)
        libXrender.so.1 => /usr/lib/x86_64-linux-gnu/libXrender.so.1 (0x00007f526d639000)
        libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f526d41e000)
        librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f526d216000)
        libffi.so.6 => /usr/lib/x86_64-linux-gnu/libffi.so.6 (0x00007f526d00c000)
        libpcre.so.3 => /lib/x86_64-linux-gnu/libpcre.so.3 (0x00007f526cd9c000)
        libICE.so.6 => /usr/lib/x86_64-linux-gnu/libICE.so.6 (0x00007f526cb7e000)
        libuuid.so.1 => /lib/x86_64-linux-gnu/libuuid.so.1 (0x00007f526c979000)
        /lib64/ld-linux-x86-64.so.2 (0x000055ef6b67d000)
        libpulsecommon-8.0.so => /usr/lib/x86_64-linux-gnu/pulseaudio/libpulsecommon-8.0.so (0x00007f526c6f8000)
        libcap.so.2 => /lib/x86_64-linux-gnu/libcap.so.2 (0x00007f526c4f2000)
        libjson-c.so.3 => /lib/x86_64-linux-gnu/libjson-c.so.3 (0x00007f526c2e7000)
        libdbus-1.so.3 => /lib/x86_64-linux-gnu/libdbus-1.so.3 (0x00007f526c097000)
        libXau.so.6 => /usr/lib/x86_64-linux-gnu/libXau.so.6 (0x00007f526be93000)
        libXdmcp.so.6 => /usr/lib/x86_64-linux-gnu/libXdmcp.so.6 (0x00007f526bc8c000)
        libatspi.so.0 => /usr/lib/x86_64-linux-gnu/libatspi.so.0 (0x00007f526ba5b000)
        libharfbuzz.so.0 => /usr/lib/x86_64-linux-gnu/libharfbuzz.so.0 (0x00007f526b7da000)
        libselinux.so.1 => /lib/x86_64-linux-gnu/libselinux.so.1 (0x00007f526b5b3000)
        libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 (0x00007f526b39b000)
        libdatrie.so.1 => /usr/lib/x86_64-linux-gnu/libdatrie.so.1 (0x00007f526b193000)
        libXtst.so.6 => /usr/lib/x86_64-linux-gnu/libXtst.so.6 (0x00007f526af8d000)
        libsystemd.so.0 => /lib/x86_64-linux-gnu/libsystemd.so.0 (0x00007f526af04000)
        libwrap.so.0 => /lib/x86_64-linux-gnu/libwrap.so.0 (0x00007f526acf9000)
        libsndfile.so.1 => /usr/lib/x86_64-linux-gnu/libsndfile.so.1 (0x00007f526aa90000)
        libasyncns.so.0 => /usr/lib/x86_64-linux-gnu/libasyncns.so.0 (0x00007f526a889000)
        libgraphite2.so.3 => /usr/lib/x86_64-linux-gnu/libgraphite2.so.3 (0x00007f526a663000)
        liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x00007f526a43f000)
        libgcrypt.so.20 => /lib/x86_64-linux-gnu/libgcrypt.so.20 (0x00007f526a131000)
        libnsl.so.1 => /lib/x86_64-linux-gnu/libnsl.so.1 (0x00007f5269f19000)
        libFLAC.so.8 => /usr/lib/x86_64-linux-gnu/libFLAC.so.8 (0x00007f5269ca2000)
        libvorbisenc.so.2 => /usr/lib/x86_64-linux-gnu/libvorbisenc.so.2 (0x00007f52699f9000)
        libgpg-error.so.0 => /lib/x86_64-linux-gnu/libgpg-error.so.0 (0x00007f52697e5000)
        libogg.so.0 => /usr/lib/x86_64-linux-gnu/libogg.so.0 (0x00007f52695db000)
        libvorbis.so.0 => /usr/lib/x86_64-linux-gnu/libvorbis.so.0 (0x00007f52693af000)
    cschramm ~ % ls -R /mnt/usr/*
    CubicSDR                vera_sans_mono16_0.png  vera_sans_mono24_0.png  vera_sans_mono48_0.png
    CubicSDR.ico            vera_sans_mono16.fnt    vera_sans_mono24.fnt    vera_sans_mono48.fnt
    vera_sans_mono12_0.png  vera_sans_mono18_0.png  vera_sans_mono32_0.png
    vera_sans_mono12.fnt    vera_sans_mono18.fnt    vera_sans_mono32.fnt
    libbladeRF.so.1  libhackrf.so.0  libliquid.so    libSoapySDR.so.0.5-1
    libfftw3f.so.3   libhamlib.so.2  librtlsdr.so.0
    libaudioSupport.so    libHackRFSupport.so  libremoteSupport.so  libsdrPlaySupport.so
    libbladeRFSupport.so  libRedPitaya.so      librtlsdrSupport.so

    I'd say such an AppImage does more harm than good as it requires a lot of specific libraries on the system without even specifying those dependencies. With the Mir issue it's less useful than a deb package as it does not even work on Debian and it probably does not work on any other system or even Ubuntu version as you will need the exact same combination of versions (like libpng16.so.16 and libFLAC.so.8).

    It looks like wxWidgets is linked statically. That's probably where the gdk_mir_display_get_type reference resides. You could either switch to dynamically linking wxWidgets (if that's possible(?)) adding yet another unspecified dependency or follow the way AppImages are meant to work and put all those linked libraries in the image which will probably get you some 100 MBs...

    My suggestion: Back to .deb unless anyone raises his hand and confirms the AppImage fits his system, while .deb doesn't.

    点赞 评论 复制链接分享
  • weixin_39775976 weixin_39775976 5月前

    It is recommended to build what goes into an AppImage on a mature distribution such as CentOS 6, and bundle everything that cannot be expected to be part of the target systems into the AppImage. This way, the binaries inside the AppImage will be most compatible.

    点赞 评论 复制链接分享
  • weixin_39733146 weixin_39733146 5月前

    Just to mention it: While the AppImage for 0.2.0-beta-rc2 contains some additional libraries now, it still expects to find the symbol gdk_mir_display_get_type and libraries like libFLAC.so.8 or libpulsecommon-8.0.so on the system, so the only two systems it targets are Ubuntu 16.04 and 16.10.

    A .deb would be smaller and more generic.

    A working AppImage with all the dependencies inside would be extraordinarily large but even more generic, yes.

    点赞 评论 复制链接分享
  • weixin_39733146 weixin_39733146 5月前

    Same for rc4.

    点赞 评论 复制链接分享
  • weixin_39601657 weixin_39601657 5月前

    I'm guessing the flatpak build is going to be the way to go moving forward; are you able to give it a try and let me know if it works out?

    点赞 评论 复制链接分享
  • weixin_39733146 weixin_39733146 5月前

    Awesome! Works like a charm for me. :+1: :+1: :+1:

    I just had to add the gnome remote as documented on http://flatpak.org/runtimes.html to be able to follow the instructions in the release notes.

    点赞 评论 复制链接分享
  • weixin_39775976 weixin_39775976 5月前

    Don't spread FUD. You do not need to switch from AppImage to Flatpak to do this. In fact, an AppImage runs everywhere whereas a Flatpack package needs to have Flatpak installed on the target system and does not work on Live systems at all.

    So the correct solution to this issue is to compile what goes into the AppImage on an "old enough" build system such as CentOS 6, as is explained on https://github.com/probonopd/AppImageKit/wiki/Creating-AppImages#creating-portable-appimages

    点赞 评论 复制链接分享
  • weixin_39733146 weixin_39733146 5月前

    : If you say it's feasible why don't you just prepare an AppImage we can try?

    点赞 评论 复制链接分享
  • weixin_39775976 weixin_39775976 5月前

    the AppImage format is designed to be used by upstream projects (application authors) to provide binaries to end users themselves, without intermediaries like packagers or distributions in between.

    That being said, here is a recipe:

    # To produce binary compatible
    # AppImages, run this on the oldest
    # version of Ubuntu/debian on which
    # the application can be compiled
    # Trying with Ubuntu 14.04
    # Install dependencies
    sudo sed -i -e 's|main|main universe|g' /etc/apt/sources.list
    sudo apt-get update
    sudo apt-get -y install git cmake libgl1-mesa-dev build-essential automake cmake libpulse-dev libgtk-3-dev freeglut3 freeglut3-dev librtlsdr-dev apt-file
    # Build and install SoapySDR
    git clone https://github.com/pothosware/SoapySDR.git
    cd SoapySDR
    mkdir build
    cd build
    cmake ../ -DCMAKE_BUILD_TYPE=Release
    make -j4
    sudo make install
    sudo ldconfig
    SoapySDRUtil --info
    cd ../..
    # Build and install liquid-dsp
    git clone https://github.com/jgaeddert/liquid-dsp
    cd liquid-dsp
    ./configure --enable-fftoverride 
    make -j4
    sudo make install
    sudo ldconfig
    cd ..
    # Build static wxWidgets
    wget https://github.com/wxWidgets/wxWidgets/releases/download/v3.1.0/wxWidgets-3.1.0.tar.bz2
    tar -xvjf wxWidgets-3.1.0.tar.bz2
    cd wxWidgets-3.1.0/
    mkdir -p ~/Develop/wxWidgets-staticlib
    ./configure --with-opengl --disable-shared --enable-monolithic --with-libjpeg --with-libtiff --with-libpng --with-zlib --disable-sdltest --enable-unicode --enable-display --enable-propgrid --disable-webkit --disable-webview --disable-webviewwebkit --prefix=`echo ~/Develop/wxWidgets-staticlib` CXXFLAGS="-std=c++0x" --with-libiconv=/usr
    make -j4
    sudo make install
    cd ..
    # Build and install SoapyRTLSDR
    git clone https://github.com/pothosware/SoapyRTLSDR.git
    cd SoapyRTLSDR
    mkdir build
    cd build
    cmake .. -DCMAKE_BUILD_TYPE=Release
    make -j4
    sudo make install
    sudo ldconfig
    cd ../..
    # Build CubicSDR
    git clone https://github.com/cjcliffe/CubicSDR.git
    cd CubicSDR
    cmake . -DENABLE_APPIMAGEKIT=1 -DCMAKE_BUILD_TYPE=Release -DwxWidgets_CONFIG_EXECUTABLE=~/Develop/wxWidgets-staticlib/bin/wx-config
    make -j4
    sudo make install
    # Generate the AppImage
    # Why is this checking which debian package owns which library
    # instead of just copying in all dependencies and then delete
    # the blacklisted libraries? This seems unneccessarily slow
    ( mkdir -p ~/Develop/AppImageKit/ ; cd ~/Develop/AppImageKit/ ; wget -c https://github.com/probonopd/AppImageKit/releases/download/5/AppRun )
    ( cd ~/Develop/AppImageKit/ ; wget -c https://github.com/probonopd/AppImageKit/releases/download/5/AppImageAssistant )
    ( cd ~/Develop/AppImageKit/ ; chmod a+x App* )
    echo "" | apt-file update
    cd ..
    wget -q https://github.com/probonopd/AppImages/raw/master/functions.sh -O ./functions.sh
    . ./functions.sh
    cd CubicSDR.AppDir/
    # We apply our standard way of handling dependencies
    # First, copy in ALL library dependencies
    # Second, move libraries in places where they can be found
    mv usr/lib/x86_64-linux-gnu/pulseaudio/* usr/lib/x86_64-linux-gnu/ && rm -r usr/lib/x86_64-linux-gnu/pulseaudio/
    mv usr/local/lib/* usr/lib && rm -r usr/local/
    # Third, delete libraries that should NOT go into the AppImage
    # (these are assumed to be part of the base system)
    find usr/ -type f  -exec sed -i -e "s|/usr/local|./////////|g" {} \;
    cd ..
    # Now generate the AppImage

    There are some strange things going on on buildAppImage.sh which I am not sure are right -- it is decided based on debian packaging information which libraries to include and which not to include.

    Hence I am using the standard way of doing this after the buildAppImage.sh script is complete; buildAppImage.sh should be changed accordingly. The resulting AppImage is much more compatible, ran successfully on Fedora 22 for example.

    点赞 评论 复制链接分享
  • weixin_39775976 weixin_39775976 5月前

    Here is the resulting AppImage built on Ubuntu 14.04.1 LTS (zipped because GitHub Issues doesn't allow to upload unzipped):


    点赞 评论 复制链接分享
  • weixin_39733146 weixin_39733146 5月前

    Works for me as well. :smiley:

    Reasons it works: Ubuntu 14.04 has... 1. GTK+ 3.10 which did not have the Mir backend (added in 3.16). 2. libpng12 which is symlinked to what is libpng16 on my system. 3. libpulsecommon-4.0 which is included in the AppImage.

    The first point means it is now incompatible with Mir systems and you're limited to the GTK+ 3.10 API of course. A Mir flavor of Ubuntu 16.10 will be shipped in three months and to me it looks like you have to decide to either stick to GTK+ 3.10 and just not support that system or use GTK+ 3.16 or later to support it, but break compatibility with systems that do not support the Mir systems. The underlying issue here is that stuff like GTK+ requires the same configuration of the build system on the target system. If the build system has Mir support, the target system needs to have it as well, so you can either ... - build on a system with Mir support (Ubuntu 15.10 and later) and run on a system with Mir support or - build on a system without Mir support and run on a system without Mir (everything except that Ubuntu flavor coming with 16.10).

    This looks like using an AppImage will lead to actually providing multiple different flavors instead of a single one, right? Another solution seems to be to include GTK in the AppImage instead of relying on the target system as I mentioned earlier which would lead to an insane size.

    Point 2 and similar situations sound like Russian roulette to me. You hope all target systems provide such a fallback for backward compatibility to the version you link to and it might or might not work. Should be fine, but means a lot of testing and if it turns out a couple of systems do not provide that you're impelled to build different flavors again.

    I have no idea of what flatpak does, but unless it has those issues as well it seems like the better alternative to me.

    点赞 评论 复制链接分享
  • weixin_39775976 weixin_39775976 5月前

    If Canonical really decides to ship a base system that is incompatible with the rest of the world, then good luck to them. I would expect(!) Mir to run X apps just fine; if it doesn't, how would you run e.g., a Firefox or OpenOffice downloaded from the original application website?

    点赞 评论 复制链接分享
  • weixin_39601657 weixin_39601657 5月前

    if I just copied everything it crashes so I was attempting to automate the decision of what to bundle and filter out the libs that would break it.

    I'll attempt to follow what you've provided instead and use your AppImage to compare.

    点赞 评论 复制链接分享
  • weixin_39601657 weixin_39601657 5月前

    Hmm, yeah the oldest I've tried building on here was Ubuntu 15.04 it seems -- doubtful any of my AppImages would have worked properly now that I'm starting to understand the issue :)

    sorry if it sounded like FUD wasn't meant to be; AppImage is still my only option for SDRPlay at the moment so it's here to stay -- just trying to implement and test as many distribution options as I can for the final builds.

    点赞 评论 复制链接分享
  • weixin_39601657 weixin_39601657 5月前

    thanks for the example script, I've based a standalone build repo on it at https://github.com/cjcliffe/CubicSDR-AppImageKit -- Just SoapyRTLSDR and SoapyRemote so far but the rest should be straightforward to add.

    Not sure why the functions.sh stuff apparently wasn't working out for me when I first tried but it's working ok now.

    点赞 评论 复制链接分享