From octave-sources-request at bevo dot che dot wisc dot edu Tue Sep  9 06:15:50 2003
Subject: Dynamic linking of .oct files and symbol names in libcruft (intrp.f 	in libcruft/villad)
From: Rudolf Seemann <kapitaen at gmx dot at>
To: octave <octave-sources at bevo dot che dot wisc dot edu>
Date: 09 Sep 2003 13:18:57 +0200

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:

[rudi at kepler]$| nm -a /usr/local/src/Mobile/lib/libMobileNumeric dot a  nm -a /usr/local/src/Mobile/lib/libMobileNumeric.a | grep
intrp
         U intrp_
intrp.o:
00000000 T intrp_
00000000 a intrp.f

[rudi at kepler]$| nm -a /usr/lib/octave-2 dot 1 dot 36/libcruft dot so  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