Cubicsdr: AppImage compatible with Ubuntu 16.04+ only

Created on 4 Jun 2016 · 20Comments · Source: cjcliffe/CubicSDR

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)

bug

Source

cschramm

All 20 comments

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

cjcliffe on 8 Jun 2016

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@y ~ % sudo mount -o loop CubicSDR.AppImage /mnt
mount: /dev/loop0 is write-protected, mounting read-only
cschramm@y ~ % 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@y ~ % ls -R /mnt/usr/*
/mnt/usr/bin:
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

/mnt/usr/lib:
libbladeRF.so.1  libhackrf.so.0  libliquid.so    libSoapySDR.so.0.5-1
libfftw3f.so.3   libhamlib.so.2  librtlsdr.so.0

/mnt/usr/local:
lib

/mnt/usr/local/lib:
SoapySDR

/mnt/usr/local/lib/SoapySDR:
modules

/mnt/usr/local/lib/SoapySDR/modules:
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@plt 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.

cschramm on 8 Jun 2016

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.

probonopd on 2 Jul 2016

👍1

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@plt 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.

cschramm on 3 Jul 2016

👍1

Same for rc4.

cschramm on 15 Jul 2016

@cschramm 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?

cjcliffe on 15 Jul 2016

👎1

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.

cschramm on 16 Jul 2016

👎1

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

probonopd on 16 Jul 2016

👍1

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

cschramm on 16 Jul 2016

@cschramm 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
./bootstrap.sh
./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
./autogen.sh
./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
./buildAppImage.sh

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

copy_deps

# Second, move libraries in places where they can be found

move_lib
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)

delete_blacklisted

patch_usr
find usr/ -type f  -exec sed -i -e "s|/usr/local|./////////|g" {} \;

cd ..

# Now generate the AppImage

APP=CubicSDR
VERSION=git
ARCH=$(arch)
generate_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.

probonopd on 16 Jul 2016

👍1

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

CubicSDR-git-x86_64.AppImage.zip

probonopd on 16 Jul 2016

👍1

Works for me as well. :smiley:

Reasons it works:
Ubuntu 14.04 has...

GTK+ 3.10 which did not have the Mir backend (added in 3.16).
libpng12 which is symlinked to what is libpng16 on my system.
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.

cschramm on 17 Jul 2016

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?

probonopd on 17 Jul 2016

@probonopd 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.

cjcliffe on 17 Jul 2016

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 :)

@probonopd 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.

cjcliffe on 17 Jul 2016

@probonopd 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.

cjcliffe on 18 Jul 2016

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

probonopd on 18 Jul 2016

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

https://github.com/cjcliffe/CubicSDR/releases/tag/0.2.0-beta-rc4

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.

cjcliffe on 20 Jul 2016

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! :)

cjcliffe on 21 Jul 2016

@cjcliffe: Works fine. :+1:

@probonopd: 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.

cschramm on 21 Jul 2016

Was this page helpful?

0 / 5 - 0 ratings