[Pkg-octave-devel] Bug#691311: error: feval: function `unimplemented' not found

[Mike Miller]

On Sat, Jan 26, 2013 at 9:52 AM, Jérémy Lal wrote:
>> On 24 October 2012 08:17, Mike Miller <mtmiller at ieee.org> wrote:
>>> The octave package provides the directories, and liboctinterp.so.1 has
>>> a compiled-in set of paths with its version number that it attempts to
>>> load.
>>
>> Ah, this is probably not the greatest idea ever. I'm not sure how to
>> fix it. Provide a build-time option for setting this path? Setting the
>> path by default to a versionless path?
>
> While not strictly forbidden, it is considered best practice to not use
> -rpath, i.e. not provide absolute paths in the shared lib.
> Is this the case here ?

Hi, thanks for commenting, and sorry I lost track of this and took so
long to follow up.

This is not an rpath problem, rather it has to do with the default
run-time path used by the Octave interpreter to dynamically load
non-built-in functions from oct-files and m-files. The run-time files
themselves are distributed between the octave and octave-common
packages. However, the strings that are used to initialize the
run-time path are stored in the liboctinterp library in the liboctave1
package.

To expand on Jordi's comments above, I can see a few ways to go about
handling this.

1) Add Depends: liboctave1 (= ${source:Version}) to octave to force
the versions of octave, octave-common, and liboctave1 to be identical.
This is the quickest and easiest way to fix this without any real
drawbacks that I see.

2) Install the run-time into non-versioned directories, e.g.
/usr/share/octave/ instead of /usr/share/octave/3.6.2. This could be
done with or without upstream support. Upstream may still want to
support co-installation of multiple Octave versions that this allows.

3) Move the strings describing the default run-time path into the
octave executable. This would probably require significant surgery.
However, if liboctave1 is really intended to be a library, then it
ideally should not have knowledge of the octave interpreter or the
functions installed in the run-time path.

I vote for #1. I don't know if there's any real benefit to keeping the
liboctave1 dependency as loose as it is now.

-- 
mike