Appimagekit: libarchive.so.14: cannot open shared object file

[TheAssassin]

./appimaged-x86_64.AppImage 
appimaged: error while loading shared libraries: libarchive.so.14: cannot open shared object file: No such file or directory

On Ubuntu 16.04, apparently appimaged won't run due to libarchive 1.4 not being shipped. This is related to #343, where @ShalokShalom reported a system was missing libarchve 1.3. The fun fact is that my system ships with libarchive 1.3 (therefore appimaged used to work a few months ago).

I think we really have to either dlopen() libarchive, or just ship our own (really not a problem for appimaged in my opinion). Or, as libarchive is really a legacy dependency to support type 1 AppImages, follow @probono's suggestion in #353. I'd ship the .so for now as a quick fix, and implement #353 as soon as possible.

[simoniz0r]

I am having the same issue.

[probonopd]

Possibly caused by https://github.com/libarchive/libarchive/issues/817. We may well want to dump libarchive altogether since the upstream project doesn't seem to be willing or able to fix this issue.

Reference:
https://github.com/AppImage/AppImageKit/wiki/Desktop-Linux-Platform-Issues

[drohm]

Is there any potential temporary workaround atm?

[simoniz0r]

Is there something stopping you from just putting libarchive in the AppImage or are you already doing this? This has been broken for quite a while now...

[drohm]

@simoniz0r I'm not actually building an AppImage, I'm wanting to use appimaged to watche locations like ~/bin and ~/Downloads for AppImages and if it detects some, registers them with the system, so that they show up in the menu, have their icons show up, MIME types associated, etc. Am I understaning the tool incorrectly?

[simoniz0r]

@drohm Sorry, that was directed at the devs, not you lol

[probonopd]

I'm wanting to use appimaged to watche locations like ~/bin and ~/Downloads for AppImages and if it detects some, registers them with the system, so that they show up in the menu, have their icons show up, MIME types associated, etc.

Correct, that's what it's supposed to do. But apparently libarchive in Ubuntu 16.04 broke due to them changing the version number for no clear reason, which makes it fail at the moment.

[simoniz0r]

What is preventing you from putting libarchive in the AppImage @probonopd ?

[probonopd]

Adding size and "bloat" just because libarchive and the distributions can't seem to agree on a version number seems odd to me. Most distributions are shipping with a perfectly suitable version of libarchive but every one seems to be naming it differently, making it impossible for us to rely on it being there.

That being said, see #355. Maybe we are forced to either statically link (preferred, as it would only bundle the subset that is really needed) it or dynamically link a private copy of it.

[TheAssassin]

@probonopd we could just drop support for type 1 AppImages as well. If it is such an effort to retain support, why bother the effort? Type 1 is deprecated, and developers should switch. I'd just show an error message instead of bothering to support them.

[ShalokShalom]

Agree +1

[simoniz0r]

@probonopd You're really concerned about ~200KBs? If I were you, I'd be more concerned about people like myself who have been trying to use appimaged for about a month now, but can't due to you not including libarchive. When most AppImages out there are Electron projects that are about 60MBs in size, I don't think many people are going to mind you adding an extra ~200KBs to your relatively small AppImage.

I'm not sure I see the problem here... should be relatively easy to include libarchive and have it work as long as it is the version that the rest of your dependencies are expecting to have. Either that or get rid of it as a dependency...

[TheAssassin]

@simoniz0r please check whether the version built in #355's Travis build (there's a transfer.sh link somewhere at the end of the log) works for you. If it does, I'll happily merge @darealshinji's work.

[simoniz0r]

@TheAssassin Yep, that build works!

[TheAssassin]

Merged #355.