Re: gcc-3.0 dynamic loading broken, preliminary patch for feedback

[Mumit Khan]

On Thu, 28 Jun 2001, John W. Eaton wrote:

> I see two other possibilities.  One is to just try to find the symbol
> with each type of mangling in turn.  Then you don't need to know the
> type of mangling in advance.  Perhaps the mangling function could even
> be defined in a .m file, so that people could more easily customize
> it.  Although this would slow things down a bit, I don't think it
> matters much, because the overhead of evaluating the .m file would
> only take place once, when the function is first loaded from the .oct
> file.

Other than debuggers and other code inspection tools, user code should
never iterate over mangling schemes. Just imagine the mess if your Octave 
is compiled with gcc-3.0, and you "successfully" load an .oct file built
with 2.95.3. The allowable mangling algorithm should always be defined 
at compile time, and not be changeable by the user, expert or novice.

My patch is coming soon, so perhaps we ought to hold off till then.
Basically, there is a new autoconf macro that figures out the C++
ABI, and octave_dynamic_loader::mangle_name() does the rest. I've
also implemented the scheme for Sun Workshop (and Tru64 C++, but that
ones untested -- the alpha I have access to is too slow to test in
real time).

> 
> Another is to eliminate the need for mangling, by declaring the
> installer function extern "C".  I think It would be easy to do this,
> by modifying the DEFINE_FUN_INSTALLER_FUN macro in defun-int.h to be:
> 
>   #define DEFINE_FUN_INSTALLER_FUN(name, doc) \
>     extern "C" bool \
>     FS ## name (const octave_shlib& shl) \
>     { \
>       check_version (OCTAVE_VERSION, #name); \
>       install_dld_function (F ## name, #name, shl, doc); \
>       return error_state ? false : true; \

This would be my preference. Instead of hacking the mangling scheme for
various releases and ABI, just get rid of the problem forever.

> but I'm not sure wheter this will work.  Can you define extern "C"
> functions that have class names and non-C types as arguments?  If this
> is possible and we choose this solution, perhaps the prefix FS should
> be made more descriptive.

extern "C" simply defines the linkage, it's still C++. Should work without
any trouble. Of course, we lose the automatic error testing that way. 

Take a look at my upcoming patch, and see if that's usable in the interim.

Regards,
Mumit