From octave-maintainers-request at bevo dot che dot wisc dot edu Fri Jun 29 14:04:19 2001
Subject: Re: [patch] Use C linkage for dynamic linking
From: Mumit Khan <khan at NanoTech dot Wisc dot EDU>
To: "John W. Eaton" <jwe at bevo dot che dot wisc dot edu>
cc: octave-maintainers at bevo dot che dot wisc dot edu, Mumit Khan <khan@NanoTech.Wisc.EDU>
Date: Fri, 29 Jun 2001 14:04:15 -0500 (CDT)

On Fri, 29 Jun 2001, John W. Eaton wrote:

> Actually, this is not the name of the function, it remains Fbesselj.
> It is the name of a function that the dynamic loader calls to install
> the function name in the symbol table, along with a pointer to the
> actual function (Fbesselj in this case).  So it should not require any
> changes to user code, even if people are calling functions using the
> Fbesselj style name (which they really shouldn't be -- they should be
> using feval instead).

You're right that user code is not affected. My terminology in the patch
note was rather vague.

Now there's the issue of being able to load existing .oct files without
having to rebuild everything. Now that Octave has decided to go the C
linkage route, is it important to provide backward compatibility for 
loading existing .oct files? If so, it could be done using a combination
of the two approaches -- have the mangler return a *list* of possible 
mangled names (eg., list containing a C linkage name and a C++ linkage 
name that's appropriate for that ABI), and octave_shlib::search will 
iterate over the list.  If this is appropriate, it's rather trivial to 
work up a patch (take a bit longer if I have to use SLList<T> instead
of std::list<T>). 

Regards,
Mumit