Re: [patch] Use C linkage for dynamic linking

[Paul Kienzle]

I agree with John.  Keep down the cruft.  This is after all nominally
an unstable version.  In the stable series I would be inclined not to
change the ABI in the first place.  

Note that I've found that .oct files compiled for 2.1.31 are rejected
by 2.1.34 (the only case of changed versions that I've tested), so the
issue is moot.

I do like the idea of keeping the name unmangled.  I'm drawn to the
idea of being able to call a shared object file directly from an m-file
without having to wrap it in C++ first.  For one thing, this would
allow all the type checking to go on in octave where it is more
convenient instead of C++.  For another, it would make it easier to
define an Octave interface to pre-existing functions.  Now the question
is how to do it efficiently without syntactic extensions.

Paul Kienzle
address@hidden

On Fri, Jun 29, 2001 at 02:38:52PM -0500, John W. Eaton wrote:
> On 29-Jun-2001, Mumit Khan <address@hidden> wrote:
> 
> | 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>). 
> 
> I don't see this as necessary, but when I install a new version of
> Octave, I typically rebuild all .oct files that I am using with it.
> Not everyone may not do that, however, so I'd like to know what other
> people think.
> 
> Thanks,
> 
> jwe
> 
>