Flatpak prevents mex linking to any system libraries

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Flatpak prevents mex linking to any system libraries

Richard Crozier
Dear List,

Just a note to say that I've done some testing, and, as is obviously the
case, installing Octave 4.4 via Flatpak prevents making any mex/oct
files which link to system libraries. This is a pretty severe
restriction for me (or rather my users). Is there any workaround for
this? Won't this affect many forge packages too?

The only alternative (since the ppa is no longer to be updated) is to
install Octave from source which is daunting for typical users.

Best regards,

Richard

--
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.


Reply | Threaded
Open this post in threaded view
|

Re: Flatpak prevents mex linking to any system libraries

Mike Miller-4
On Mon, Jul 09, 2018 at 17:00:28 +0100, Richard Crozier wrote:
> Just a note to say that I've done some testing, and, as is obviously the
> case, installing Octave 4.4 via Flatpak prevents making any mex/oct files
> which link to system libraries. This is a pretty severe restriction for me
> (or rather my users). Is there any workaround for this? Won't this affect
> many forge packages too?

For your definition of "system libraries", which I'm assuming is not the
same as my definition. I will continue assuming you mean "a particular
mathematical or scientific library which is not part of a standard
operating system installation."

This is more of a Flatpak question than an Octave question.

The question could be worded as, how does Flatpak plan to accomodate
applications that allow dynamic loading of plugins or extensions that
may depend upon other libraries that are not part of the Flatpak
runtime?

I am not a Flatpak maintainer so I can only guess, but my guess would be
that they will expect the extension to download or bundle everything
with it. This is similar to the typical Python pip module distribution
model, where e.g. NumPy bundles copies of FFTPACK and LAPACK, and PyQt5
bundles a copy of the entire Qt 5 runtime.

> The only alternative (since the ppa is no longer to be updated)

That is not true, the PPA will be updated when Octave 4.4 is in Ubuntu.
But I do hope that most users will find the Flatpak app to be a viable
solution for their use case, when they care more about using Octave and
less about integration with the operating system.

> is to
> install Octave from source which is daunting for typical users.

That's not the only alternative. You can install or copy the libraries
needed into a user's home directory, or you can bundle the libraries
with the mex or oct code.

If it is a typical numeric library, it should be easier to build and
install that in a user's home directory than to build and install Octave
from source.

Or you can try building your own Octave package for Ubuntu using the
Debian source package, to try to get ahead of the Ubuntu maintainers.

--
mike

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Flatpak prevents mex linking to any system libraries

Richard Crozier
On 09/07/18 19:04, Mike Miller wrote:

> For your definition of "system libraries", which I'm assuming is not the
> same as my definition. I will continue assuming you mean "a particular
> mathematical or scientific library which is not part of a standard
> operating system installation."
>


Yes, sorry, I mean any libraries in /usr/* which is not accessible to
the Octave Flatpack version.


> This is more of a Flatpak question than an Octave question.
>
> The question could be worded as, how does Flatpak plan to accomodate
> applications that allow dynamic loading of plugins or extensions that
> may depend upon other libraries that are not part of the Flatpak
> runtime?
>
> I am not a Flatpak maintainer so I can only guess, but my guess would be
> that they will expect the extension to download or bundle everything
> with it. This is similar to the typical Python pip module distribution
> model, where e.g. NumPy bundles copies of FFTPACK and LAPACK, and PyQt5
> bundles a copy of the entire Qt 5 runtime.
>


ok I had a look and found some things about extensions:

https://github.com/flatpak/flatpak-docs/issues/18

This might work for forge packages where you know the package exists in
advance, but still doesn't help with user-built mex or oct files which
link to libraries in /usr/*


>> The only alternative (since the ppa is no longer to be updated)
>
> That is not true, the PPA will be updated when Octave 4.4 is in Ubuntu.
> But I do hope that most users will find the Flatpak app to be a viable
> solution for their use case, when they care more about using Octave and
> less about integration with the operating system.
>


ok, sorry, I misunderstood some earlier correspondence on this. The
thing is, lots of forge packages use libraries from /usr/local, e.g.
odepkg, netcdf etc. Basically anything that provides an interface a C++
library for Octave. I think typical users will have an expectation of
using these packages, rather than just bare Octave.


>> is to
>> install Octave from source which is daunting for typical users.
>
> That's not the only alternative. You can install or copy the libraries
> needed into a user's home directory, or you can bundle the libraries
> with the mex or oct code.
>


This has problems because you can't easily build portable libraries on
Linux, mainly due to libc, so users would have to build them, or I would
have to do the copying on the user's system in a script or something,
which seems likely to break, and become complex depending on library
versions etc. It also means these libraries won't be updated with, e.g.
'apt upgrade' since they're just a copy in some random location.


> If it is a typical numeric library, it should be easier to build and
> install that in a user's home directory than to build and install Octave
> from source.


ok but that starts to get seriously complicated, for example I have a
project which uses the mbdyn, the gnu scientific library, and f2c. I
don't really fancy making my users find, download and build all of
these. I already make them install MBDyn, which is painful enough.


> Or you can try building your own Octave package for Ubuntu using the
> Debian source package, to try to get ahead of the Ubuntu maintainers.
>


I think my solution will be to create bash install scripts for each
flavour of Linux I choose to support and point users to them, maybe I'll
also put them on the Octave wiki. This is not ideal, but I suppose my
real issue is that I require Octave 4.4 rather than 4.2 which what is
commonly available in package repositories.

Regards,

Richard

--
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.