weird problem with __magick_read__.oct

[John W. Eaton]

I recently noticed that imread wasn't working for me.  Looking closer,
I found that __magick_read__ was not defined.  Trying "help
__magick_read__" produced the error

  error: help: `__magick_read__' not found

I thought maybe a recent upgrade caused some problem with the
GraphcsMagick library on my system (Debian testing).  Perhaps some
undefined symbols or something.  But that doesn't seem to be it
because I found that if I changed the name of the function to
magick_read, it worked again.  I.e., I just made the following change
and recompiled:

diff --git a/src/DLD-FUNCTIONS/__magick_read__.cc 
b/src/DLD-FUNCTIONS/__magick_read__.cc
--- a/src/DLD-FUNCTIONS/__magick_read__.cc
+++ b/src/DLD-FUNCTIONS/__magick_read__.cc
@@ -344,7 +344,7 @@
 
 #endif
 
-DEFUN_DLD (__magick_read__, args, nargout,
+DEFUN_DLD (magick_read, args, nargout,
   "-*- texinfo -*-\n\
 @deftypefn {Function File} address@hidden =} __magick_read__(@var{fname}, 
@var{index})\n\
 @deftypefnx{Function File} address@hidden, @var{colormap}] =} 
__magick_read__(@var{fname}, @var{index})\n\

Looking at the output of "nm __magick_read__.oct" before this change,
I see:

  0000000000010ce7 T G__magick_read__
  0000000000015da5 T _Z16F__magick_read__RK17octave_value_listi

which looks correct (when looking for the DEFUN function "fcn" in a
.oct file, Octave searches the .oct file for a function with the name
"Gfcn" (with C-linkage), then calls that function to install the
actual C++ function that is callable from the interpreter -- that's
the one with the mangled name).  In stepping through
octave_dlopen_shlib::search I see that dlsym fails to return a pointer
for the symbol "G__magick_read__" even though one appears to be
present in the .oct file.

Stepping through the search function also showed that the library is
loaded correctly, but the symbol is not found, so it doesn't appear to
be an undefined symbol problem.

I thought maybe it had something to do with the leading/trailing
underscores of the function name, but I don't see how.  I don't have
problems with __pchip_deriv__.oct, for example.

Changing the prefix from "G" to something else (I tried "OCTAVE")
doesn't seem to have any effect.

Also, the simple program

  #include <dlfcn.h>
  #include <iostream>
  #include <string>

  int
  main (int argc, char **argv)
  {
    bool ok = false;

    void *lib = dlopen (argv[1], RTLD_NOW);

    if (lib)
      {
        void *f = dlsym (lib, argv[2]);

        if (f)
          ok = true;
      }

    if (ok)
      std::cerr << "success" << std::endl;
    else
      {
        const char *msg = dlerror ();
        std::cerr << msg << std::endl;
      }

    return 0;
  }

fails when I run it as

  LD_LIBRARY_PATH=libcruft:liboctave:src ./a.out src/__magick_read__.oct 
G__magick_read__

but succeeds when I do

  LD_LIBRARY_PATH=libcruft:liboctave:src ./a.out src/__magick_read__.oct 
_Z16F__magick_read__RK17octave_value_listi

(I'm running it in my build tree for the current Octave sources).

The fact that the second symbol is found also tends to support the
idea that the call to dlopen to load the .oct file is probably not the
problem.

Note that we can't easily look for the C++ function directly because
we would have to know the name mangling scheme used by the C++
compiler, and that might not be easy to determine.

I'm stumped.

Any ideas?

Can anyone else reproduce this problem?

jwe