[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

linking external library

From: John W. Eaton
Subject: linking external library
Date: Tue, 25 Aug 1998 11:59:22 -0500 (CDT)

On 25-Aug-1998, Cyril Fischer <address@hidden> wrote:

| I would like to create an *.oct file containing call to the (large)
| external library using a mkoctfile script:
| mkoctfile -limsl
| mkoctfile -L/home/Libr/imsl/imsl -limsl-stat
| In the first case I  have linked against /usr/local/lib/
| shared library,
| in the later case against /home/Libr/imsl/imsl/libimsl-stat.a static
| library.
| 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:
| dsswp___FPiPdT0T1T0T0T1
| 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:

  LD_AOUT_PRELOAD=/usr/local/lib/ 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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]