In the first case I have linked against /usr/local/lib/libimsl.so
in the later case against /home/Libr/imsl/imsl/libimsl-stat.a static
The size of an oct-file produced was in the both cases the same and the
run time errors were exactly identical::
| I would like to create an *.oct file containing call to the (large)
| external library using a mkoctfile script:
| mkoctfile dsswp_wr.cc -limsl
| mkoctfile dsswp_wr.cc -L/home/Libr/imsl/imsl -limsl-stat
| In the first case I have linked against /usr/local/lib/libimsl.so
| shared library,
| in the later case against /home/Libr/imsl/imsl/libimsl-stat.a static
| The size of an oct-file produced was in the both cases the same and the
| run time errors were exactly identical::
| octave:53> s=dsswp_wr(prd,fr,m);
| octave: error in loading shared libraries
| /home/msig/octave/dsswp_wr.oct: undefined symbol:
| What am I doing wrong?
| Unfortunately, I cannot separate the subroutine dsswp_ out of the
| library due to the huge number of dependencies.
What kind of system are you using?
It may be that the OS doesn't know which directory to look in to find
the library, or it may be that dependencies on shared libraries that
are loaded using dlopen() are not resolved automatically.
I have seen this kind of problem before on Digital Unix systems and
Linux systems, but I don't have a really good solution. My workaround
was to do something like this when running Octave:
Does anyone know whether shared library dependencies should be
resolved automatically by dlopen(), and if so, how to make it happen
reliably on most systems?
If that's not possible, perhaps mkoctfile should record in the .oct
file the names of the libraries listed with -l options and then Octave
could link them in when it loads the .oct file.