Re: [Matlisp-users] matlisp migration trouble (missing symbol)

[rif <ri...@MI...>]

Thanks for the tip.  I think the problem has to do with the fact that
on my laptop, the ATLAS libraries are dynamic, but on the new machine,
they're static.  So when matlisp itself gets loaded, in the dynamic
library case, it can get at all the symbols, so I can access dpotrf_
later.  Its in the *static* case that if it doesn't already need
dpotrf_, it doesn't bother importing it.  I "fixed" it on the new
machine by explicitly loading the lapack library specifically, and
that did fix the immediate problem.

However, I am beginning to believe (largely for the reasons mentioned
by Tunc) that a better solution is for me to extend matlisp itself
prior to matlisp compilation (and keep patches so that I can apply to
new downloads of matlisp).  At this point, I believe that I can do
this by modifying lazy-loader.c and matlisp.mk.in to add the desired
routine, adding a lisp routine that calls define-fortran-function, and
adding a mention of the file containing this routine to system.dcl.
Is there anything else I should need to touch?  Does this seem like a
reasonable approach?

rif

> Hey,
> 
> Try adding an external declaration and a dummy call to "dpotrf_"
> in the file lazy-loader.c.  Then do a remake.
> 
> I originally picked the name "lazy" loader because, upon loading
> a dynamic library, on some platforms, only those symbols which are
> explicitly referenced were being loaded.  This is the purpose of
> the dummy call.
> 
> ----- Original Message -----
> From: rif <ri...@MI...>
> Date: Monday, December 20, 2004 3:25 pm
> Subject: Re: [Matlisp-users] matlisp migration trouble (missing symbol)
> 
> > 
> > > >>>>> "rif" == rif  <ri...@MI...> writes:
> > > 
> > >     rif> Once matlab is loaded, I have a file where I def-
> > fortran-routine
> > >     rif> dpotrf.  This scheme works fine on my laptop, but on 
> > the other
> > >     rif> machine, when I try to load this file, I get the error:
> > > 
> > >     rif> Undefined foreign symbol: "dpotrf_"
> > >     rif>    [Condition of type KERNEL:SIMPLE-PROGRAM-ERROR]
> > > 
> > > This sounds like dpotrf is not in the matlisp LAPACK/BLAS library.
> > > Are you sure both platforms have identical libraries?  It may happen
> > > that we don't compile all the LAPACK routines if we don't have a
> > > matlisp interface to them.
> > > 
> > > Ray
> > 
> > OK, my understanding is increasing, but I'm not all the way there yet.
> > As I now understand, matlisp does not by default load all of lapack,
> > but only what it needs.  When you specify --with-atlas= at config
> > time, matlisp loads the atlas lapack library (this is also a 
> > subset of
> > lapack, but it contains the routines I need).  So this explains 
> > why my
> > stuff doesn't work without atlas, on either the laptop or the new
> > machine.
> > 
> > What I still don't get is why, when I specify a --with-atlas=, it
> > works on the laptop but not the new machine.  Looking into
> > lazy-loader.lisp, part of the call to ext::load-foreign includes the
> > arguments (to be tokenized):
> > 
> > "-L/cbcl/cbcl01/rif/Software/ATLAS/lib/Linux_P4SSE2_4/" " " "-llapack
> > -lcblas -lf77blas -latlas" " "
> > 
> > This code is clearly being run (if I add some made-up library name I
> > get an error), so it's finding (and AFAIK loading) the libraries it
> > wants.  Furthermore, dpotrf_ appears to be in the library:
> > 
> > [rif@node-06 Linux_P4SSE2_4]$ pwd
> > /cbcl/cbcl01/rif/Software/ATLAS/lib/Linux_P4SSE2_4
> > [rif@node-06 Linux_P4SSE2_4]$ nm liblapack.a  | grep dpotrf_
> > 00000000 T atl_f77wrap_dpotrf__
> >         U atl_f77wrap_dpotrf__
> > 00000000 T dpotrf_
> > 
> > Nevertheless, when I try to compile and then load a file 
> > containing a
> > def-foreign-function for dpotrf, it fails on this machine with an
> > "Undefined symbol dpotrf_ error" (this works on my laptop).  Note that
> > I seem to be able to just load the .lisp file directly, but compiling
> > it then loading it yields the undefined symbol error --- I don't know
> > if this is relevant.
> > 
> > In case anyone wants it, I've put the file matlisp-ext-lapack.lisp in
> > http://fpn.mit.edu/Downloads.  My goal is to, after loading matlisp,
> > be able to compile and load this file.
> > 
> > As a side question, is there any easy way to tell what exactly library
> > files ext::load-foreign is actually picking up?  This could be helpful
> > for debugging purposes.
> > 
> > Again, any help is appreciated.
> > 
> > Cheers,
> > 
> > rif
> > 
> > 
> > -------------------------------------------------------
> > SF email is sponsored by - The IT Product Guide
> > Read honest & candid reviews on hundreds of IT Products from real 
> > users.Discover which products truly live up to the hype. Start 
> > reading now. 
> > http://productguide.itmanagersjournal.com/
> > _______________________________________________
> > Matlisp-users mailing list
> > Mat...@li...
> > https://lists.sourceforge.net/lists/listinfo/matlisp-users
> > 
>