Re: weird problem with __magick_read__.oct

[Jaroslav Hajek]

On Thu, Jun 25, 2009 at 4:50 PM, John W. Eaton<address@hidden> wrote:
> 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\
> address@hidden {Function File} address@hidden =} __magick_read__(@var{fname}, 
> @var{index})\n\
> address@hidden 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
>

I don't see the problem. Also, using your test loader, both loads are
successful for me.
My kernel is 2.6.25, glibc is 2.8. System is x86_64.

regards

-- 
RNDr. Jaroslav Hajek
computing expert & GNU Octave developer
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz