From octave-maintainers-request at bevo dot che dot wisc dot edu Fri Jun 29 13:48:13 2001
Subject: Re: gcc-3.0 dynamic loading broken, preliminary patch for feedback
From: "John W. Eaton" <jwe at bevo dot che dot wisc dot edu>
To: Mumit Khan <khan at NanoTech dot Wisc dot EDU>
Cc: "John W. Eaton" <jwe at bevo dot che dot wisc dot edu>,        octave-maintainers@bevo.che.wisc.edu
Date: Fri, 29 Jun 2001 13:47:50 -0500

On 28-Jun-2001, Mumit Khan <khan at NanoTech dot Wisc dot EDU> wrote:

| 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.

OK, good points.

| > 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. 

I don't think that is a big problem, since the only recommended way of
creating these functions is to use the DEFUN macros, and we alreay
check version info when functions are loaded.  If there is an
interface change, the version number should change.  Not that people
won't find a way to screw things up, but at least they would have to
work pretty hard to do it.  Harder even if we changed the version
check to produce an error by default instead of just a warning.

jwe