Octave-mmclab packaging query: loading mex files

[Ankur Sinha]

Hiya,

I'm reviewing an octave package[1] that generates an arch specific mex
file. As I understand it, this should go to
/usr/lib64/octave/packages/%{name}-%{version} (%{octpkglibdir}), while
the other noarch files go to
/usr/share/octave/packages/%{name}-%{version} (%{octpkgdir}). This is
the case:
> drwxr-xr-x  /usr/lib64/octave/packages/mmclab-1.7.9
>  -rwxr-xr-x  /usr/lib64/octave/packages/mmclab-1.7.9/mmc.mex
>  drwxr-xr-x  /usr/share/doc/octave-mmclab
>  -rw-r--r--  /usr/share/doc/octave-mmclab/AUTHORS.txt
>  -rw-r--r--  /usr/share/doc/octave-mmclab/README.txt
>  drwxr-xr-x  /usr/share/licenses/octave-mmclab
>  -rw-r--r--  /usr/share/licenses/octave-mmclab/LICENSE.txt
>  drwxr-xr-x  /usr/share/octave/packages/mmclab-1.7.9
>  -rw-r--r--  /usr/share/octave/packages/mmclab-1.7.9/besselhprime.m
>  -rw-r--r--  /usr/share/octave/packages/mmclab-1.7.9/besseljprime.m
>  -rw-r--r--  /usr/share/octave/packages/mmclab-1.7.9/besselyprime.m
>  -rw-r--r--  /usr/share/octave/packages/mmclab-1.7.9/cart2sphorigin.m
>  ...

However, @fangq (CC'd) reports that the mex file does not load in
Octave[2].  The path() in octave does not return %{octpkglibdir} either
when I check it. Could someone please point out what we're missing here?

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1760617
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1760617#c28

[Jerry James]

On Tue, Feb 18, 2020 at 5:01 AM Ankur Sinha  wrote:
> However, @fangq (CC'd) reports that the mex file does not load in
> Octave[2].  The path() in octave does not return %{octpkglibdir} either
> when I check it. Could someone please point out what we're missing here?

This affects the libsvm package as well.  If I put its .mex file into
%{octpkglibdir}, it won't load.  If I put it into %{octpkgdir}, then
it loads.  This looks like an octave bug.

[Orion Poplawski]

On 2/18/20 5:00 AM, Ankur Sinha wrote:
> Hiya,
>
> I'm reviewing an octave package[1] that generates an arch specific mex
> file. As I understand it, this should go to
> /usr/lib64/octave/packages/%{name}-%{version} (%{octpkglibdir}), while
> the other noarch files go to
> /usr/share/octave/packages/%{name}-%{version} (%{octpkgdir}). This is
> the case:
> > drwxr-xr-x  /usr/lib64/octave/packages/mmclab-1.7.9
> >   -rwxr-xr-x  /usr/lib64/octave/packages/mmclab-1.7.9/mmc.mex
> >   drwxr-xr-x  /usr/share/doc/octave-mmclab
> >   -rw-r--r--  /usr/share/doc/octave-mmclab/AUTHORS.txt
> >   -rw-r--r--  /usr/share/doc/octave-mmclab/README.txt
> >   drwxr-xr-x  /usr/share/licenses/octave-mmclab
> >   -rw-r--r--  /usr/share/licenses/octave-mmclab/LICENSE.txt
> >   drwxr-xr-x  /usr/share/octave/packages/mmclab-1.7.9
> >   -rw-r--r--  /usr/share/octave/packages/mmclab-1.7.9/besselhprime.m
> >   -rw-r--r--  /usr/share/octave/packages/mmclab-1.7.9/besseljprime.m
> >   -rw-r--r--  /usr/share/octave/packages/mmclab-1.7.9/besselyprime.m
> >   -rw-r--r--  /usr/share/octave/packages/mmclab-1.7.9/cart2sphorigin.m
> >   ...
>
> However, @fangq (CC'd) reports that the mex file does not load in
> Octave[2].  The path() in octave does not return %{octpkglibdir} either
> when I check it. Could someone please point out what we're missing here?
>
> [1] https://bugzilla.redhat.com/show_bug.cgi?id=1760617
> [2] https://bugzilla.redhat.com/show_bug.cgi?id=1760617#c28

There is also an API and arch/host directory involved:

path() in octave reports:
/usr/lib64/octave/4.4.1/site/oct/x86_64-redhat-linux-gnu
/usr/lib64/octave/site/oct/api-v52/x86_64-redhat-linux-gnu
/usr/lib64/octave/site/oct/x86_64-redhat-linux-gnu
/usr/lib64/octave/4.4.1/oct/x86_64-redhat-linux-gnu

and for example, an octave package will install it's library in:

/usr/lib64/octave/packages/netcdf-1.0.12/x86_64-redhat-linux-gnu-api-v52/__netcdf__.oct

See also:

%octave_host %(octave-config -p CANONICAL_HOST_TYPE || echo 0)
%octave_api %(octave-config -p API_VERSION || echo 0)

[Ankur Sinha]

On Tue, Feb 18, 2020 21:21:19 -0700, Orion Poplawski wrote:
> <snip>
> There is also an API and arch/host directory involved:
>
> path() in octave reports:
> /usr/lib64/octave/4.4.1/site/oct/x86_64-redhat-linux-gnu
> /usr/lib64/octave/site/oct/api-v52/x86_64-redhat-linux-gnu
> /usr/lib64/octave/site/oct/x86_64-redhat-linux-gnu
> /usr/lib64/octave/4.4.1/oct/x86_64-redhat-linux-gnu
>
> and for example, an octave package will install it's library in:
>
> /usr/lib64/octave/packages/netcdf-1.0.12/x86_64-redhat-linux-gnu-api-v52/__netcdf__.oct
>
> See also:
>
> %octave_host %(octave-config -p CANONICAL_HOST_TYPE || echo 0)
> %octave_api %(octave-config -p API_VERSION || echo 0)

Ah! Thanks Orion! That makes sense. I put the mex file in the right
%{octpkglibdir}/%{octave_host}-%{octave_api} folder and now it is loaded
properly.

Do you think this should/could be added to the guidelines? It doesn't
mention %{octave_host} for example, and a note that says something like
"For arch specific bits, Octave looks at
%{octpkglibdir}/%{octave_host}-%{octave_api}" would help us novice
octave packagers. I suspect a few of us aren't aware of this bit :)