From octave-maintainers-request at bevo dot che dot wisc dot edu Thu Jun 28 15:39:33 2001 Subject: gcc-3.0 dynamic loading broken, preliminary patch for feedback From: "John W. Eaton" To: Mumit Khan Cc: octave-maintainers at bevo dot che dot wisc dot edu Date: Thu, 28 Jun 2001 15:39:14 -0500 On 28-Jun-2001, Mumit Khan wrote: | Those of who're trying out Octave CVS with gcc-3.0, you'll notice that | dynamic loading is broken, something that I had completely missed. Thanks | to Christoph Spiel for pointing out the obvious. | | I have a preliminary patch that does the right thing depending on GNU C++ | ABI (v2 aka old, or v3 aka new, and supposedly forever stable), but I need | to write up a autoconf macro for this, and take care of a few other gritty | details such as checking for underscore prefix etc. | | I'm including a temporary patch, but please don't depend on this. This is | not meant to go into CVS as is. I'm looking for feedback at this point on | how to do this correctly. I have thought about including the GNU C++ | demangling code, but that's a bit more work than I'd like to do at this | point. 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. 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; \ } 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. jwe