Skip to content
Prev 27146 / 63461 Next

Problem with dyn.load'ed code

Simon,
	Thanks for the reply. Indeed, declaring the function static fixes the
example. Unfortunately, the real problem that gave rise to the example
arises in a large Fortran library that is not under my control (ARPACK).
The author is providing BLAS and LAPACK functionality intentionally.
That may or may not be good practice, but it is a given in this case.
	So, I have a set of Fortran code in which some BLAS functionality is
replicated. I am writing an interface to some of the functions in that
code (not to the BLAS part, that is used internally by ARPACK). I would
like it if that interface did not require alteration of the library
source code or build process (though it is open-source, so if need be I
can change it). 
	I still feel like the linker ought to be able to solve this problem for
me. My impression was that the static keyword passed to the linker
caused it to resolve all references at link time. So something like:

ld -o my_code_and_arpack.o -static my_code.o -larpack

would pull all the references from the two object files (my_code.o and
libarpack.a) and link them as needed, and unresolved references would
cause an error. I guess that impression is wrong, but how does one
accomplish the same thing? 
	Thanks for any help,

	Matt
On Sun, 2007-12-30 at 20:21 -0500, Simon Urbanek wrote: