Need help building an AppImage for GNU Octave

[fusion809]

Hi,

Before you ask me to request an AppImage upstream the answer is that this is a GNU Project, they only provide source code, no binary builds. Here is my present yaml:

app: Octave

ingredients:
  package: octave
  dist:    trusty
  sources:
    - deb http://archive.ubuntu.com/ubuntu/ trusty main universe
  ppas:
    - octave/stable

script:
  - sed -i -e 's|/usr/bin/||g' www.octave.org-octave.desktop
  - mv www.octave.org-octave.desktop octave.desktop

while it builds fine, the AppImage gives the error:

/bin/bash: ../lib/x86_64-linux-gnu/libtinfo.so.5: no version information available (required by /bin/bash)
/home/fusion809/.cache/thumbnails/normal/106ab48d0f68b0cd4e0df7cc56808f3d.png is missing. Probably not running ./bin//octave.wrapper from within an AppImage.
Hence falling back to using .DirIcon
octave: failed to exec '/usr/lib/x86_64-linux-gnu/octave/4.0.2/exec/x86_64-pc-linux-gnu/octave-gui'

usr/lib/x86_64-linux-gnu/octave/4.0.2/exec/x86_64-pc-linux-gnu/octave-gui does exist in the AppImage. The usr/bin/octave file is not a shell script, so I can't simply try tweaking it. It's a binary.

and fails to launch.

Thanks for your time, Brenton

[probonopd]

AppImage is a tool that empowers upstream application authors to ship binaries to end users without intermediaries. If the GNU project is not interested in this, then we won't get binaries directly from the GNU project and must live with whatever the distribution happens to ship. Personally I avoid anything coming from GNU for that very attitude, use the MIT license rather than LGPL, and try to move away from GNU tools if viable alternatives exist.

I really try to help any upstream project that wants to ship AppImages, but I don't offer the same level of support to work around uninterested projects like GNU that seem to have no interest in binary compatibility.

[fusion809]

I just asked for help in the #octave IRC channel and suffice it to say they weren't really receptive. They don't do chat logging so I can't share that. Here's my copy-pasted log:

fusion809 Howdy folks. I was wondering if there's any interest among the developers of GNU Octave to provide a cross-distribution package for GNU Octave on Linux? I have made an attempt to build one myself but that failed (for details on how and why see this GitHub issue https://github.com/probonopd/AppImages/issues/120). JordiGH fusion809: One distribution is work enough. mtmx I have a very slight interest in playing with Flatpak at some point fusion809 True and precisely why building one package that will work on all distributions is a good investment of time. Would save hundreds of hours working on packages for each individual distribution. JordiGH I generally don't like the idea of being empowered to ship binaries without distributions. JordiGH fusion809: It won't save the hours, it'll just accumulate them all in one point. JordiGH I'm old and cranky and I think all ye kids thinking that debs and rpms are dumb are just unaware of the problems these things solve. mtmx the problem with a cross-distro packaging project is that there are already at least 3 competing standards JordiGH Or even better: someone comes up with a C++-specific package manager. JordiGH Like every other language's language-specific package manager. JordiGH Can't wait for cppget install octave fusion809 Yes it would, as each distribution has a very different system for packaging. Writing spec files, Debian package files (like rules files), PKGBUILDs, ebuilds and alike would suck up a lot more time than writing one Recipe or yaml file to build an AppImage or one yaml file to build a snap package. JordiGH fusion809: In exchange for having to ship giant monoliths that do not play nicely with the OS and suck up tons of bandwidth and would probably have to be updated anyways when Linux upgrades. JordiGH I mean, go ahead and do it, but I'll grump about it every step of the way. JordiGH I'm sure others will love it. fusion809 mtmx: yep there are three competing standards. So why not choose one that doesn't require root privileges in order to be run, like AppImages. Granted I'll be happy even if AppImages aren't used but rather flatpaks or snap packages are used. JordiGH Also, these one-size-fits-all solutions are usually just a bit naïve about how many different sizes there are. JordiGH one-size-fits-all doesn't even work for macOS, and there you're just targetting supposedly a single OS. mtmx fusion809: it looks like your github issue was closed, so there's really nothing worth working on there, is there? fusion809 It was closed because we couldn't go anywhere without help from the upstream developers. Hence why I'm here. mtmx if you are asking for GNU Octave the project to build and maintain an AppImage binary, then no that is definitely not going to happen mtmx if you are asking for help on a specific error or failure, we might be able to help fusion809 OK, well does this channel have a log? If so I'd like to share it so I can document that I've at least given upstream a chance to help us. mtmx no logging JordiGH Just show them your own log. JordiGH It's text. JordiGH copy-paste it. JordiGH fusion809: We already tried a one-size-fits-all thing. It's MXE. It's a lot of work and it doesn't quite work for everything. mtmx Can you clarify what kind of help you are looking for? JordiGH fusion809: Also, that probonopd person is quite obnoxious and thinks that we have some sort of ideological opposition to shipping binaries because of the GPL or something. JordiGH It's not because of the GPL. It's because we tried it, doesn't work, and Octave is just way too complicated for a one-size-fits-all solution. Or at least that's my grumpy explanation. And now I want to argue with probonopod about how wrong they are in their opinions.

[probonopd]

Not going to comment on everything, but on this one:

JordiGH: Also, that probonopd person is quite obnoxious and thinks that we have some sort of ideological opposition to shipping binaries because of the GPL or something.

I've never said that. It just looks to me like the primary concern of all things GNU is the openness of the code, whereas AppImage is designed for application authors that want to have end-to-end control over the end user (!= developer) experience without any intermediaries between the author and the user (aka "polished end-user experience"). It also happens that most GNU code is indeed picked up by most distributions, whereas applications in the "long tail" (think your local school's scheduling application) cannot be expected to show up in each Linux distribution.

So let's just say that the goals of the GNU project and the nature of GNU software as well of the GNU core audience. In my experience, GNU developers' concerns don't align with the concerns of AppImage as much as, say, Qt cross-platform application developers or Electron-based cross-platform application developers which are much more concerned about end users, and, as a result, much more receptive to the ideas of bundling systems such as AppImage (which they already know about from the other two desktop platforms they are already serving). Let's work with those folks.

So, some people will get the Emacs source code, compile it and use that, while others will download Atom from the Atom website and use that. Choice is good. Let's not try to force things upon anyone.

[fusion809]

Don't worry JordiGH had a bite at me too later. Saying I dislike them because they love the GPL. Rofl, if you look at my original repositories (i.e., ones I haven't forked) you will see that at least 90% of them use the GPLv3 license.

[probonopd]

While I try to use the MIT License wherever I can, I don't have anything against the GPL. Just be aware that some companies will try to stay away from everything GPL if they can.

My point is that even if you care about the openness of the source, that doesn't have to mean that you don't care about a polished end-user experience or the availability of ready-to-use binaries...

[fusion809]

True. The GNU Project, IMO, is still in the early 90s ideologically, thinking that Linux isn't to be user-friendly or polished, it's meant to be a user free-for-all, rofl. Or, alternatively, they think packagers should do all the polishing for them and package every new release for users, and by-and-large distro packagers tend to package once and forget about it until the next release of the distro (as is the case for Ubuntu it seems).

[probonopd]

"GNU/Linux" that is ;-)

[fusion809]

Ah btw I saw your GNU Octave Recipe (https://github.com/probonopd/AppImages/blob/master/recipes/octave/Recipe) and tried to build it but it failed. I have tried modifying it to get it to work and it's gotten stuck at line 22. Your AppImageKit doesn't contain a CMakeLists.txt file. Is it necessary for you to build AppImageAssistant in the CentOS 6 container? Or was that written before you started to provide binaries for it? I'm asking because I want to know if I can simply switch those lines for a downloading the AppImageAssistant binary you provide.

[probonopd]

AppImageAssistant has been replaced by appimagetool. The recipe was written by @crayxt and I don't have much clue about it, sorry.

[jordigh]

Guys, I'm still here. I can hear you.

We are not against usability nor against making Octave distributable because of GNU. In fact, several of us help with Octave packaging for Debian. I have done some of that, and so has Mike Miller. We are also not stuck in the 90s, since we gave Octave a GUI after a lot of work. Because of this GUI, we are Qt cross-platform developers. We have to make sure Octave works on Windows, macOS, the BSDs and so forth. A lot of work went into making sure Octave could be compiled for Windows.

We are not opposed to what you're doing. It's just a lot of work and I'm very skeptical it can work better than what we're doing, but like I told @fusion809, I'm eager to be proven wrong.

[jordigh]

Oh, one more thing. If you're able to create "universal" Octave binaries along with an easy recipe for reproducing them, I see no problem with including this recipe in our sources as well as distributing the binaries alongside these binaries for Windows:

http://alpha.gnu.org/gnu/octave/

My grumping is just skepticism, not a refusal.

[fusion809]

@jordigh Ye art more polite 'ere than in the IRC. Didn't hear any eagerness at all in the IRC. But I'm glad you seem to have come around. I'm working in two veins to get an AppImage for GNU Octave available. Firstly I'm working on that RPM-based AppImage and I'm also trying to create a Ubuntu 14.04 package for GNU Octave 4.2.0 so that I can then use that to build an AppImage.

[jordigh]

Sorry, like I said, I probably was just hungry when I was grumping at you. (Not an excuse, just an explanation.) I did try to exhort you to prove me wrong.

[fusion809]

@jordigh Well I got just got an error that maybe you can help me with. On a CentOS 6 Docker container I got the error:

configure: error: in `/Octave/octave-4.2.0':
configure: error: C++ preprocessor "/lib/cpp" fails sanity check
See `config.log' for more details

config.log is here. Any ideas?

[fusion809]

Rofl never mind, I figured it out. The Recipe I copied from this repo didn't install gcc-c++.

[fusion809]

Now I'm getting:

  CC       sys_socket.lo
  CC       tempname.lo
  CC       glthread/threadlib.lo
  CC       glthread/tls.lo
  CC       tmpdir.lo
  CC       u64.lo
  CC       unistd.lo
  CC       dup-safer.lo
  CC       fd-safer.lo
  CC       pipe-safer.lo
  CC       wctype-h.lo
  CC       xmalloc.lo
  CC       xalloc-die.lo
  CC       xgetcwd.lo
  CC       xsize.lo
  CC       xstrndup.lo
  CC       asnprintf.lo
  CC       chdir-long.lo
  CC       fcntl.lo
  CC       fnmatch.lo
  CC       getcwd.lo
  CC       getcwd-lgpl.lo
  CC       getopt.lo
  CC       getopt1.lo
  CC       glob.lo
  CC       mbrtowc.lo
  CC       mktime.lo
  CC       nanosleep.lo
  CC       openat-proc.lo
  CC       printf-args.lo
  CC       printf-parse.lo
  CC       secure_getenv.lo
  CC       time_rz.lo
  CC       vasnprintf.lo
  CCLD     libgnu.la
make[4]: Leaving directory `/Octave/octave-4.2.0/libgnu'
make[3]: Leaving directory `/Octave/octave-4.2.0/libgnu'
make[2]: Leaving directory `/Octave/octave-4.2.0/libgnu'
preserving existing HG-ID file
make[2]: Entering directory `/Octave/octave-4.2.0'
  CXX      libinterp/dldfcn/libinterp_dldfcn___delaunayn___la-__delaunayn__.lo
In file included from /usr/lib/gcc/x86_64-redhat-linux/4.4.7/../../../../include/c++/4.4.7/cstdint:35,
                 from ./oct-conf-post.h:186,
                 from ./config.h:3485,
                 from libinterp/dldfcn/__delaunayn__.cc:42:
/usr/lib/gcc/x86_64-redhat-linux/4.4.7/../../../../include/c++/4.4.7/c++0x_warning.h:31:2: error: #error This file requires compiler and library support for the upcoming ISO C++ standard, C++0x. This support is currently experimental, and must be enabled with the -std=c++0x or -std=gnu++0x compiler options.
In file included from ./liboctave/array/Array.h:37,
                 from libinterp/corefcn/Cell.h:31,
                 from libinterp/dldfcn/__delaunayn__.cc:50:
./liboctave/array/dim-vector.h:205: warning: variadic templates only available with -std=c++0x or -std=gnu++0x
./liboctave/array/dim-vector.h:207: warning: variadic templates only available with -std=c++0x or -std=gnu++0x
./liboctave/array/dim-vector.h: In constructor ‘dim_vector::dim_vector(octave_idx_type, octave_idx_type, Ints ...)’:
./liboctave/array/dim-vector.h:207: warning: variadic templates only available with -std=c++0x or -std=gnu++0x
./liboctave/array/dim-vector.h:209: error: ‘initializer_list’ is not a member of ‘std’
./liboctave/array/dim-vector.h:209: error: expected primary-expression before ‘>’ token
./liboctave/array/dim-vector.h:209: error: ‘all_lengths’ was not declared in this scope
./liboctave/array/dim-vector.h:209: warning: extended initializer lists only available with -std=c++0x or -std=gnu++0x
./liboctave/array/dim-vector.h:210: error: expected initializer before ‘:’ token
./liboctave/array/dim-vector.h:213: error: expected primary-expression before ‘}’ token
./liboctave/array/dim-vector.h:213: error: expected ‘)’ before ‘}’ token
./liboctave/array/dim-vector.h:213: error: expected primary-expression before ‘}’ token
./liboctave/array/dim-vector.h:213: error: expected ‘;’ before ‘}’ token
In file included from ./liboctave/array/Array.h:38,
                 from libinterp/corefcn/Cell.h:31,
                 from libinterp/dldfcn/__delaunayn__.cc:50:
./liboctave/array/idx-vector.h: At global scope:
./liboctave/array/idx-vector.h:68: error: ‘unique_ptr’ in namespace ‘std’ does not name a type
In file included from libinterp/corefcn/Cell.h:31,
                 from libinterp/dldfcn/__delaunayn__.cc:50:
./liboctave/array/Array.h:282: warning: variadic templates only available with -std=c++0x or -std=gnu++0x
./liboctave/array/Array.h:861: warning: variadic templates only available with -std=c++0x or -std=gnu++0x
./liboctave/array/Array.h: In constructor ‘Array<T>::Array(const Container<T>&, const dim_vector&)’:
./liboctave/array/Array.h:876: error: expected initializer before ‘:’ token
./liboctave/array/Array.h:880: error: expected primary-expression before ‘}’ token
./liboctave/array/Array.h:880: error: expected ‘)’ before ‘}’ token
./liboctave/array/Array.h:880: error: expected primary-expression before ‘}’ token
./liboctave/array/Array.h:880: error: expected ‘;’ before ‘}’ token
In file included from libinterp/corefcn/Cell.h:32,
                 from libinterp/dldfcn/__delaunayn__.cc:50:
./liboctave/util/str-vec.h: At global scope:
./liboctave/util/str-vec.h:59: warning: variadic templates only available with -std=c++0x or -std=gnu++0x
./liboctave/util/str-vec.h:59: warning: variadic templates only available with -std=c++0x or -std=gnu++0x
./liboctave/util/str-vec.h:130: warning: variadic templates only available with -std=c++0x or -std=gnu++0x
./liboctave/util/str-vec.h:130: warning: variadic templates only available with -std=c++0x or -std=gnu++0x
./liboctave/util/str-vec.h: In constructor ‘string_vector::string_vector(const String_Container<std::basic_string<char, std::char_traits<char>, std::allocator<char> >, Other ...>&)’:
./liboctave/util/str-vec.h:138: error: expected initializer before ‘:’ token
./liboctave/util/str-vec.h:140: error: expected primary-expression before ‘}’ token
./liboctave/util/str-vec.h:140: error: expected ‘;’ before ‘}’ token
./liboctave/util/str-vec.h:140: error: expected primary-expression before ‘}’ token
./liboctave/util/str-vec.h:140: error: expected ‘)’ before ‘}’ token
./liboctave/util/str-vec.h:140: error: expected primary-expression before ‘}’ token
./liboctave/util/str-vec.h:140: error: expected ‘;’ before ‘}’ token
In file included from libinterp/corefcn/error.h:31,
                 from ./libinterp/octave-value/ov-base.h:40,
                 from ./libinterp/octave-value/ov.h:57,
                 from libinterp/corefcn/Cell.h:33,
                 from libinterp/dldfcn/__delaunayn__.cc:50:
./liboctave/util/unwind-prot.h: In member function ‘virtual void octave::unwind_protect::run_first()’:
./liboctave/util/unwind-prot.h:73: error: ‘unique_ptr’ is not a member of ‘std’
./liboctave/util/unwind-prot.h:73: error: expected primary-expression before ‘>’ token
./liboctave/util/unwind-prot.h:73: error: ‘ptr’ was not declared in this scope
In file included from ./libinterp/octave-value/ov-fcn.h:33,
                 from ./libinterp/octave-value/ov-builtin.h:30,
                 from libinterp/corefcn/defun-int.h:30,
                 from libinterp/corefcn/defun-dld.h:32,
                 from libinterp/dldfcn/__delaunayn__.cc:51:
./libinterp/octave-value/ovl.h: At global scope:
./libinterp/octave-value/ovl.h:57: warning: variadic templates only available with -std=c++0x or -std=gnu++0x
./libinterp/octave-value/ovl.h:188: warning: variadic templates only available with -std=c++0x or -std=gnu++0x
./libinterp/octave-value/ovl.h:190: warning: variadic templates only available with -std=c++0x or -std=gnu++0x
./libinterp/octave-value/ovl.h: In function ‘octave_value_list ovl(const OV_Args& ...)’:
./libinterp/octave-value/ovl.h:192: error: ‘initializer_list’ is not a member of ‘std’
./libinterp/octave-value/ovl.h:192: error: expected primary-expression before ‘(’ token
./libinterp/octave-value/ovl.h:192: error: ‘initializer_list’ is not a member of ‘std’
./libinterp/octave-value/ovl.h:192: error: expected primary-expression before ‘>’ token
./libinterp/octave-value/ovl.h:192: error: expected ‘;’ before ‘...’ token
In file included from liboctave/operators/mx-ext.h:54,
                 from ./liboctave/array/Matrix.h:34,
                 from ./liboctave/util/lo-regexp.h:34,
                 from libinterp/corefcn/symtab.h:36,
                 from ./libinterp/octave-value/ov-fcn.h:36,
                 from ./libinterp/octave-value/ov-builtin.h:30,
                 from libinterp/corefcn/defun-int.h:30,
                 from libinterp/corefcn/defun-dld.h:32,
                 from libinterp/dldfcn/__delaunayn__.cc:51:
liboctave/numeric/svd.h: At global scope:
liboctave/numeric/svd.h:43: warning: scoped enums only available with -std=c++0x or -std=gnu++0x
liboctave/numeric/svd.h:50: warning: scoped enums only available with -std=c++0x or -std=gnu++0x
liboctave/numeric/svd.h:60: error: ‘octave::math::svd::Type’ is not a class or namespace
liboctave/numeric/svd.h:61: error: ‘octave::math::svd::Driver’ is not a class or namespace
libinterp/dldfcn/__delaunayn__.cc: In function ‘octave_value_list F__delaunayn__(const octave_value_list&, int)’:
libinterp/dldfcn/__delaunayn__.cc:197: warning: use of old-style cast
make[2]: *** [libinterp/dldfcn/libinterp_dldfcn___delaunayn___la-__delaunayn__.lo] Error 1
make[2]: Leaving directory `/Octave/octave-4.2.0'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/Octave/octave-4.2.0'
make: *** [all] Error 2

[crayxt]

@fusion809 it could be that compiler is too old, check with epel-7 chroot.

[fusion809]

My Debian package attempt at building an AppImage has gone further than my attempt at using CentOS. I have an AppImage but whenever I run it I get the error:

/bin/bash: /tmp/.mount_d5Q1Q7/lib/x86_64-linux-gnu/libtinfo.so.5: no version information available (required by /bin/bash)
/usr/lib/x86_64-linux-gnu/octave/4.2.0/exec/x86_64-pc-linux-gnu/octave-gui: /tmp/.mount_d5Q1Q7/usr/lib/libgl2ps.so.0: no version information available (required by
 /usr/lib/x86_64-linux-gnu/octave/4.2.0/liboctinterp.so.4)
/usr/lib/x86_64-linux-gnu/octave/4.2.0/exec/x86_64-pc-linux-gnu/octave-gui: /tmp/.mount_d5Q1Q7/usr/lib/x86_64-linux-gnu/libgomp.so.1: version `GOMP_4.0' not found
(required by /usr/lib/libGraphicsMagick-Q16.so.3)

any ideas @probonopd or anyone else? Here is my yaml:

app: Octave
union: true

ingredients:
  package: octave
  dist:    trusty
  sources:
    - deb http://archive.ubuntu.com/ubuntu/ trusty main universe
  ppas:
    - brentonhorne/octave

script:
  - sed -i -e 's|/usr/bin/||g' www.octave.org-octave.desktop
  - mv www.octave.org-octave.desktop octave.desktop
  - cp ./usr/share/octave/4.*/imagelib/octave-logo.svg octave.svg

Oh and yes that does mean I have created a working GNU Octave PPA that provides four separate sets of Debian binaries: those for 32-bit Trusty, 64-bit Trusty, 32-bit Xenial and 64-bit Xenial.

[probonopd]

Looks like usr/lib/x86_64-linux-gnu/libgomp.so.1 needs to be at least version GOMP_4.0. Does it work using the same ppas without the AppImage?

[fusion809]

Do you mean does the GNU Octave package in the brentonhorne/octave PPA's Trusty repository work? If so yes I have tested it in a Docker container for Trusty and it works fine.

[probonopd]

Honestly I don't know. I am not an expert in GNU Octave, in libgomp, nor in compiling stuff in general, sorry. This kind of thing is best handled by the people who wrote the software and are knowledgeable about it, imho. AppImage just gives them the tool which they could but don't have to use. I am not interested in reverse-engineering/second-guessing how to compile and/or package others' software, except for cases where the original authors need such help.

[fusion809]

If they would do this stuff themselves I wouldn't be bothering creating an AppImage myself.

[probonopd]

Right ;-)

[jordigh]

If they would do this stuff themselves I wouldn't be bothering creating an AppImage myself.

Well, now you see why we don't do it ourselves: this is a lot of work, and most of our users using GNU-based distributions are already able to install Octave from their repos. I am glad to see you working on it yourself, though.

I have worked on the Debian package in the past. I know how to build Octave using the Debian repos to fetch the dependencies, but libgomp is a new one to me. Oh, it's for OpenMP, which is kind of part of gcc. It's very strange you're getting a version mismatch. Are you mixing gcc versions?

Are you already following the build instructions for Debian?

I don't know yet how AppImages work. I was hoping you could easily translate a deb or rpm into this new packaging format. What does your yaml recipe do? Obviously it doesn't just grab the Ubuntu source package and build it in the version of Ubuntu that it's known to work in, because, well: that would have worked. Or are you trying to update the Debian packaging for that PPA?

It appears you grabbed some unknown bloke's PPA. Try this one instead, maintained by our own Mike Miller (mtmx in IRC), who also works on the Debian packaging. I expect the 4.2 release from Thursday will be there soon.

[probonopd]

I don't know yet how AppImages work. I was hoping you could easily translate a deb or rpm into this new packaging format. What does your yaml recipe do?

Normally a .yml should do exactly what you describe: grab debs from a repository/ppa and convert them into an AppImage. Now, in this case the brentonhorne/octave ppa is used which is made by @fusion809 himself...

[fusion809]

Yeah brentonhorne/octave is my PPA. I forked it from mtmx's as his was out-of-date. Using his packages gives the error I opened this issue with. No we're not mixing GCC versions, just using that provided by Trusty in the build of the original Debian package in my repo. That Debian package works fine in a Trusty Docker image so I doubt it's a straightforward issue with the packages themselves.

[jordigh]

Hm, it's out of date by two days. 4.2 was just released on Thursday. There's a Debian packaging in experimental for the 4.1.0 unreleased development version, which probably can be adapted for Ubuntu. I expect Mike will update the official PPA soon, after 4.2 lands in Debian.

Is there a way to get a more informative error message from the original message? Why did it fail to execute?The 4.0 official PPA does provide the GUI.

[fusion809]

4.2 has been out since the 14th of November (Monday), or at least its source code has been https://ftp.gnu.org/gnu/octave/. As for getting a more verbose error message I'm not sure, @probonopd any ideas?

[jordigh]

So, the octave wrapper is a shim binary that should fork+exec into octave-gui or octave-cli. So I assume the fork worked but the exec didn't.

Can you execute octave-gui directly?

[fusion809]

Running octave from within the AppDir works fine and confirms that 4.2 was released on 14 November 2016 (note the line that says "The Octave Developers, Nov 14, 2016").

Does seem odd that it runs fine, but when I uninstall GNU Octave from my system on which I'm testing it does give an error:

/usr/lib/x86_64-linux-gnu/octave/4.2.0/exec/x86_64-pc-linux-gnu/octave-gui: failed to exec '/usr/lib/x86_64-linux-gnu/octave/4.2.0/exec/x86_64-pc-linux-gnu/octave-gui'

Which is much the same as the error I opened this issue with. It seems to me like the octave and octave-cli binaries are not portable and maybe that's somehow causing this error. Especially my original error that I opened this issue with, the one from the octave/stable PPA. AppImages work best when the binaries they're made from are portable. Which is why where possible we build them from binary tarballs instead of Debian packages.

[jordigh]

What's an AppDir directory? What were you running it under before where it didn't work?

What does "portable" mean in this case? Does it mean it should statically link all dependencies? What's the difference between a binary tarball and a Debian package?

[fusion809]

AppDir is what we make AppImages from. See AppImages are disk images (built with SquashFS) made by compressing AppDirs. Portable in this context means that it doesn't call on an absolute file location (like /usr/lib/x86_64-linux-gnu/octave/4.2.0/exec/x86_64-pc-linux-gnu/octave-gui) in one's file system, it calls on a relative location (e.g., the octave binary might call on the relative location ../lib/x86_64-linux-gnu/octave/4.2.0/x86_64-pc-linux-gnu/octave-gui instead of the absolute location /usr/lib/x86_64-linux-gnu/octave/4.2.0/x86_64-pc-linux-gnu/octave-gui).

Binary tarballs are archives which contain all the files required to run the program and when they are extracted (like any tarball) an executable binary file inside can be run (e.g., one called octave for a GNU Octave tarball). The beauty of binary tarballs is that you can move them anywhere in your file system, extract them and run them without a problem. This property of them also makes them fit the definition of "portable".

Debian packages, on the other hand, contain files that are designed to be placed in very specific places in your local file system when they're installed (e.g., for an GNU Octave package the octave binary is meant to be placed in /usr/bin the octave-gui file is meant to be placed in /usr/lib/x86_64-linux-gnu/octave/4.2.0/exec/x86_64-pc-linux-gnu/). Many of them depend on these very specific locations in order for them to be properly run (as they call on absolute paths instead of relative paths). This is what makes their contents not necessarily portable.

I hope I explained this clearly as I am trying my best.

[jordigh]

Oh, I see, you guys are recreating macOS app bundles for GNU-based distros.

So, binary tarballs require you to bundle all of the dependencies, correct? They don't have to statically link them, but they have to ship them. For this purpose, it might be far easier to try to go with MXE than Debian packages. MXE will download and compile most of Octave's dependencies. It stops at system things like X and glibc, though.

It will require deep surgery into Octave's build system to make all of those paths relative. They are all defined at configure time.

[probonopd]

Yes, AppImage is kinda like an Apple .app inside a .dmg.

For relocateability, there are solutions like binreloc and I wonder why not more projects are using them.

Isn't MXE Windows-only? We don't want or need to bundle system things like X and glibc.

[fusion809]

@probonopd Na MXE is not Windows only, the MXE article at the Octave Wiki (http://wiki.octave.org/MXE) has Linux-only instructions even. I'm trying a build to see if I can adapt MXE into an AppImage.

[probonopd]

Wow, that'd be awesome.

This is working for me, gives 4.0.2:

app: Octave
union: true

ingredients:
  package: octave
  dist:    trusty
  sources:
    - deb http://archive.ubuntu.com/ubuntu/ trusty main universe
  ppas:
    - octave/stable

script:
  - sed -i -e 's|/usr/bin/||g' www.octave.org-octave.desktop
  - mv www.octave.org-octave.desktop octave.desktop
  - mv ./usr/lib/x86_64-linux-gnu/octave/*/*.so* ./usr/lib/x86_64-linux-gnu/ # Subdirectory to allow for alternatives. But libs are not found there
  - mv ./usr/lib/lapack/*.so* ./usr/lib/ # Subdirectory to allow for alternatives. But libs are not found there
  - mv ./usr/lib/libblas/*.so* ./usr/lib/ # Subdirectory to allow for alternatives. But libs are not found there
  - ( cd ./usr/lib/x86_64-linux-gnu/octave/*/ ; ln -s ../../exec/ . ) # WTF?!
  - ( cd usr/lib/ ; ln -s libblas.so.3 libblas.so.3gf ) # gf stands for gfortran
  - ( cd usr/lib/ ; ln -s liblapack.so.3 liblapack.so.3gf ) # gf stands for gfortran

Why does https://launchpad.net/octave not have 4.2.0? Now you know why I don't like repositories that are not made by upstream - they just always seem to be lagging behind. In contrast, love how I can download the KDevelop AppImage on the day the application is released.

[fusion809]

Nice, as for MXE its build failed on Ubuntu 16.04 with error:

[download] gnutls
[build]    gnutls

Failed to build package gnutls!
------------------------------------------------------------
  ***
  *** Libnettle 2.7.1 was not found. Note that this version of gnutls doesn't support nettle 3.0.
/home/fusion809/Programs/MXE-Octave/mxe-octave-64063cd35eb2/Makefile:801: recipe for target 'build-only-gnutls' failed
make[2]: *** [build-only-gnutls] Error 1
make[2]: Leaving directory '/home/fusion809/Programs/MXE-Octave/mxe-octave-64063cd35eb2'
real    0m22.494s
user    0m17.800s
sys     0m0.624s
------------------------------------------------------------
[log]      /home/fusion809/Programs/MXE-Octave/mxe-octave-64063cd35eb2/log/gnutls

Makefile:801: recipe for target '/home/fusion809/Programs/MXE-Octave/mxe-octave-64063cd35eb2/installed-packages/gnutls' failed
make[1]: *** [/home/fusion809/Programs/MXE-Octave/mxe-octave-64063cd35eb2/installed-packages/gnutls] Error 1
make[1]: Leaving directory '/home/fusion809/Programs/MXE-Octave/mxe-octave-64063cd35eb2'
Makefile:523: recipe for target 'all' failed
make: *** [all] Error 2

[fusion809]

For me your yaml fails with error:

+ bash -ex /tmp/recipe_script
+ sed -i -e 's|/usr/bin/||g' www.octave.org-octave.desktop
+ mv www.octave.org-octave.desktop octave.desktop
+ mv ./usr/lib/x86_64-linux-gnu/octave/4.0.2/liboctgui.so ./usr/lib/x86_64-linux-gnu/octave/4.0.2/liboctgui.so.1 ./usr/lib/x86_64-linux-gnu/octave/4.0.2/liboctgui.
so.1.1.0 ./usr/lib/x86_64-linux-gnu/
+ cd ./usr/lib/x86_64-linux-gnu/octave/4.0.2/ ./usr/lib/x86_64-linux-gnu/octave/api-v50+/ ./usr/lib/x86_64-linux-gnu/octave/packages/ ./usr/lib/x86_64-linux-gnu/oc
tave/site/
+ ln -s ../../exec/ .
ln: failed to create symbolic link './exec': File exists

[probonopd]

Btw, using your ppa @fusion809 the following seems to work:

app: Octave
union: true

ingredients:
  package: octave
  dist:    trusty
  sources:
    - deb http://archive.ubuntu.com/ubuntu/ trusty main universe
  ppas:
    - brentonhorne/octave

script:
  - sed -i -e 's|/usr/bin/||g' www.octave.org-octave.desktop
  - mv www.octave.org-octave.desktop octave.desktop
  - mv ./usr/lib/x86_64-linux-gnu/octave/*/*.so* ./usr/lib/x86_64-linux-gnu/ # Subdirectory to allow for alternatives. But libs are not found there
  - mv ./usr/lib/lapack/*.so* ./usr/lib/ # Subdirectory to allow for alternatives. But libs are not found there
  - mv ./usr/lib/libblas/*.so* ./usr/lib/ # Subdirectory to allow for alternatives. But libs are not found there
  - ( cd usr/lib/ ; ln -s libblas.so.3 libblas.so.3gf ) # gf stands for gfortran
  - ( cd usr/lib/ ; ln -s liblapack.so.3 liblapack.so.3gf ) # gf stands for gfortran
  - cp ./usr/share/octave/4.2.0/imagelib/octave-logo.svg octave.svg

But do you promise to keep your ppa up to date, so that on each GNU Octave release date you will have the latest in your ppa? See, another reaon why I'd prefer upstream to do it....

[jordigh]

- mv ./usr/lib/lapack/*.so* ./usr/lib/ # Why don't they put it there? - mv ./usr/lib/libblas/*.so* ./usr/lib/ # Why don't they put it there? - ( cd usr/lib/ ; ln -s libblas.so.3 libblas.so.3gf ) # What stupidity is this? - ( cd usr/lib/ ; ln -s liblapack.so.3 liblapack.so.3gf ) # What stupidity is this?

Can we keep the snide remarks to a minimum? I'm honestly trying to understand you guys. If we both think the other side is just a bunch of incompetent idiots, we're not going to get anywhere. I get that AppImages is an opinionated project that thinks everything is stupid and broken, but there really are reasons for that.

To answer your questions, LAPACK underwent a transition from gcc to gfortran, which is what "gf" stands for. The gf suffix was dropped long ago, but some things might still want it. Additionally, there are several atlernative implementations of LAPACK and BLAS, such as ATLAS, MKL, or OpenBLAS. These are fundamental, old, and very reliable linear algebra libraries used by all scientific computing packages. The reason the libraries are above /usr/lib is to allow alternative versions and implementation concurrently and to allow Octave (or any other scientific computing package) to dynamically switch implementation at dynamic link time.

Love teh gnu* ;-)

Please stop.

[fusion809]

Well I've always had a love of Octave, so I'll try.

[probonopd]

@jordigh sorry if the comments offended you. It's just that I have never seen any library need suffixes like "gf" appended to a .so name and it's hard as an "outsider" to understand the purpose of those. Besides, the "gf" libraries are simply not found unless I specifically symlink them there. Stuff like this can drive the occasional user nuts. Anyhow, thanks for your explanation. Will edit the comments.

[jordigh]

*\ Libnettle 2.7.1 was not found. Note that this version of gnutls doesn't support nettle 3.0.

Hm, this is strange. Nettle should be built by MXE-Octave too. I wonder if somehow gnutls is finding your system nettle instead of the one that MXE built. Do you see nettle 2.7.1 getting built before gnutls?

[fusion809]

Well nettle is listed as one package built built:

[download] nettle                                                                                              
[build]    nettle                                                                                              
[done]     nettle

Is there a way to mask my system installation of nettle from it? Uninstalling nettle will uninstall a few pieces of software I'd rather not go without.

[fusion809]

@probonopd your yaml for my PPA fails for me. It builds fine but when run it gives the same error as I got:

/bin/bash: /tmp/.mount_1QSzpI/lib/x86_64-linux-gnu/libtinfo.so.5: no version information available (required by /bin/bash)
/usr/lib/x86_64-linux-gnu/octave/4.2.0/exec/x86_64-pc-linux-gnu/octave-gui: /tmp/.mount_1QSzpI/usr/lib/libgl2ps.so.0: no version information available (required by
 /usr/lib/x86_64-linux-gnu/octave/4.2.0/liboctinterp.so.4)
/usr/lib/x86_64-linux-gnu/octave/4.2.0/exec/x86_64-pc-linux-gnu/octave-gui: /tmp/.mount_1QSzpI/usr/lib/x86_64-linux-gnu/libgomp.so.1: version `GOMP_4.0' not found
(required by /usr/lib/libGraphicsMagick-Q16.so.3)

[probonopd]

Now that's interesting... because it runs for me and I don't have any local GNU Octave installed. But I do have local ImageMagick installed, maybe this is making a difference? Just guessing here.

[probonopd]

@fusion809 is there a way in MXE to specify a specific (old) glibc?

[fusion809]

I was one step ahead, rofl, I uninstalled GNU Octave before testing the AppImage. I have ImageMagick installed locally. I'll give it a try in a clean Ubuntu 16.10 VM and Fedora 24 VM. If it works there I'll be happy with your YAML. As for specifying an old glibc I haven't the foggiest. I don't know much about MXE at all, just what that Octave Wiki article says and what I've heard in the #octave IRC channel.

[probonopd]

Oops, on Fedora-Workstation-Live-x86_64-24-1.2.iso I get

/usr/lib/x86_64-linux-gnu/octave/4.2.0/exec/x86_64-pc-linux-gnu/octave-gui: error while loading shared libraries: libcurl-gnutls.so.4: cannot open shared object file: No such file or directory`.

On ubuntu-14.04.1-desktop-amd64.iso it runs cleanly though.

So far, I had blacklisted the libcurl3-gnutls deb but it seems like we cannot assume this library to be part of each base system.

EDIT: Added that library, now runs on Fedora 24 too. (Delete any pre-existing Octave folder you might have from previous runs and re-run the recipe, then it gets the updated excludedeblist.)

[probonopd]

On openSUSE-Tumbleweed-GNOME-Live-x86_64-Snapshot20160921-Media.iso and on CentOS-7-x86_64-LiveGNOME-1511.iso I get:

p11-kit: couldn't load module: /usr/lib/x86_64-linux-gnu/pkcs11/p11-kit-trust.so: /usr/lib/x86_64-linux-gnu/pkcs11/p11-kit-trust.so: cannot open shared object file: No such file or directory p11-kit: couldn't load module: /usr/lib/x86_64-linux-gnu/pkcs11/gnome-keyring-pkcs11.so: /usr/lib/x86_64-linux-gnu/pkcs11/gnome-keyring-pkcs11.so: cannot open shared object file: No such file or directory

Nevertheless it seems to run.

On debian-live-8.4.0-amd64-gnome-desktop.iso, elementaryos-0.4-stable-amd64.20160921.iso, and linuxmint-17.3-cinnamon-64bit.iso it runs fine too.

Gotta love binary compatibility.