Re: mkoctfile oct extension using shared libraries

[Mike Miller]

Hi Richard,

On Sun, Sep 22, 2019 at 10:56:45 -0700, Richard Tobias wrote:
> This works as follows with Matlab:
> 
> LD_LIBRARY_PATH=<correct directories to run> matlab
> Then I call the .mexa64 file with and everything is fine.
> 
> Now trying the same method with octave:
> 
> LD_LIBRARY_PATH=<correct directories to run> octave
> Call the test code and it fails with a missing symbol from a .so that is
> called.

I think we may need more information to help you with this. This
normally works with Octave oct files and looks correct to me, given what
you have shown so far. Is the project available for someone else to try?
What is the library and what is the missing symbol? Have you tried
building with '-rpath' instead of relying on LD_LIBRARY_PATH? Does 'ldd'
show that the .so is found?

> LD_LIBRARY_PATH=<correct directories to run> flatpak run octave
> 
> This doesn't get anywhere as a bunch of boost libraries are missing as I'm
> sure the flatpak doesn't have the necessary libraries installed.  Note that
> we use some less frequently used boost libraries in our  .oct/.mex code.
> Actually, flatpak is probably the wrong way to do this if someone wants to
> extend Octave with their own very complicated set of libraries as flatpak
> will not have the libraries in the flatpak environment and it seems like it
> doesn't look at your current LD_LIBRARY_PATH, etc.  Which of course is the
> case when you have your own SW interface to a new piece of HW.  I have
> tried:
> 
> flatpak --env=LD_LIBRARY_PATTH=$LD_LIBRARY_PATTH:/usr/lib/x86_64-linux-gnu
> run org.octave.Octave
> 
> with the same result.

Flatpak runs programs in a confined environment by design, but certain
directories are available to the Octave Flatpak. If the libraries you
need to link are in /home, /opt, or /srv, then the files should be
visible. If the libraries are in /usr, then they will not be accessible.

-- 
mike

signature.asc
Description: PGP signature