Dynamic linking of .oct files and symbol names in libcruft (intrp.f in libcruft/villad)

[John W. Eaton]

[I'm moving this to the help-octave mailing list.  The octave-sources
mailing list is for posting source code.  --jwe]

On  9-Sep-2003, Rudolf Seemann <address@hidden> wrote:

| Hey!
| 
| I am using GNU Octave, version 2.1.36 (i686-pc-linux-gnu) on a redhat
| 8.0 machine. Since I have to use a powerful mechanical library called
| Mobile which depends on netlib - routines, loading an oct file "g++
| -shared" - linked to this library seemed the best to me. Seemed...
| 
| It took me some time to figure out why my program executed properly as
| standalone application but segfaulted as oct-dynamic-object in octave.
| The mechanical library depends on numerical routines written in fortran
| (published at netlib.org).
| 
| One of these routines is "intrp(x,yy,tout,y,ypout,neqn,kold,phi,psi)".
| The same name is used in villad/intrp.f "INTRP ( ND, NT, X, ROOT, DIF1,
| XINTP )" in libcruft. See the following bash commands:
| 
| address@hidden nm -a /usr/local/src/Mobile/lib/libMobileNumeric.a | grep
| intrp
|          U intrp_
| intrp.o:
| 00000000 T intrp_
| 00000000 a intrp.f
| 
| address@hidden nm -a /usr/lib/octave-2.1.36/libcruft.so | grep intrp
| 00048db0 T intrp_
| 00000000 a intrp.f
| 
| If the program is executed and it calls intrp then the version in
| libcruft is executed instead of the one statically linked in the
| oct-file and the program fails.
| 
| Except of renaming the functions - which is an awkward solution I have
| no idea how to solve this problem.
| 
| Thanks in advance
| Rudi

I don't know of a general and portable solution other than renaming.
If the only place you need to access your intrp function is inside
your own .oct file, then you might be able to restrict the scope of
the name to just that file, at least on some systems (sorry, I don't
know what compiler flags to use).

Should we try to solve this problem in the Octave sources?

Octave's own .oct files and the liboctinterp, liboctave, and libcruft
libraries do not try to hide symbols because the idea is to allow
access to the complete internals of Octave.  So perhaps it would be
better to have some kind of naming convention (or actual C++
namespaces) instead.

Most of Octave already uses some kind of prefix for global symbols,
either something like octave_ or lo_ or whatever, or member functions
are hidden by their class names, or global C++ functions have mangled
names anyway.  Some of these could still cause conflicts.  Does anyone
have any suggestions for a systematic way of fixing this?

jwe




-------------------------------------------------------------
Octave is freely available under the terms of the GNU GPL.

Octave's home on the web:  http://www.octave.org
How to fund new projects:  http://www.octave.org/funding.html
Subscription information:  http://www.octave.org/archive.html
-------------------------------------------------------------