Re: mkoctfile oct extension using shared libraries

[Richard Tobias]

Hi,

Thank you for the suggestions.  I tried -R and I get 

g++: error: unrecognized command line option ‘-R’

I also see that -R is not a g++ flag.  What I did was copy all of the -L's in the mkoctfile and added a similar -R.

Basically, in my makefile I did this:

RLIBDIR = $(subst -L,-R,$(LIBDIR))

And then added both $(RLIBDIR) and $(LIBDIR) to the mkoctfile command line.

Unfortunately, it is hard to release the SW as is to show the issue.  I will figure out how to create a simple example to show the issue.

One thing to note is the libraries are in the -L's and are someplace in my build tree under /home/<user name>.

While I figure out an example I can at least quickly show the picture of what is going on:

• /home/rjjt/libs/libA.so   <--- c++11 stuff that is build into a .so with class CoolStuffClass and member function doSomething
• /home/rjjt/octs/myOctStuff.oct this routine creates a class CoolStuffClass and calls the doSomething member function
• mkoctfile -L/home/rjjt/libs -lA myOctStuff.cc -output /home/rjjt/octs/myOctStuff

Creates /home/rjjt/octs/myOctStuff

LD_LIBRARY_PATH=/home/rjjt/libs octave&

>>>> myOctStuffFunctionThatCallsCoolStuffClass

Then it says in the normal cryptic name mangled way that it can't find CoolStuffClass::doSomething

Using c++filt you can get to CoolStuffClass::doSomething which is a program that unmangles the mangled name in the ELF/oct file.

ldd /home/rjjt/octs/myOctStuff.oct | grep libA.so

Returns that it is part there and with the correct path.

 

Richard

On Sun, Sep 22, 2019 at 12:33 PM Mike Miller <address@hidden> wrote:

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