Re: weird problem with __magick_read__.oct

[Thorsten Meyer]

John W. Eaton 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\
>  @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
> 

I think, I see the same problem (also on debian (mostly) testing). In the tests,
I have the following failure:

  ***** test
 vpng = [ ...
  137,  80,  78,  71,  13,  10,  26,  10,   0,   0, ...
    0,  13,  73,  72,  68,  82,   0,   0,   0,   3, ...
    0,   0,   0,   3,   8,   2,   0,   0,   0, 217, ...
   74,  34, 232,   0,   0,   0,   1, 115,  82,  71, ...
   66,   0, 174, 206,  28, 233,   0,   0,   0,   4, ...
  103,  65,  77,  65,   0,   0, 177, 143,  11, 252, ...
   97,   5,   0,   0,   0,  32,  99,  72,  82,  77, ...
    0,   0, 122,  38,   0,   0, 128, 132,   0,   0, ...
  250,   0,   0,   0, 128, 232,   0,   0, 117,  48, ...
    0,   0, 234,  96,   0,   0,  58, 152,   0,   0, ...
   23, 112, 156, 186,  81,  60,   0,   0,   0,  25, ...
   73,  68,  65,  84,  24,  87,  99,  96,  96,  96, ...
  248, 255, 255,  63, 144,   4,  81, 111, 101,  84, ...
   16,  28, 160,  16,   0, 197, 214,  13,  34,  74, ...
  117, 213,  17,   0,   0,   0,   0,  73,  69,  78, ...
   68, 174,  66,  96, 130];
 fid = fopen('test.png', 'wb');
 fwrite(fid, vpng);
 fclose(fid);
 A = imread('test.png');
 delete('test.png');
 assert(A(:,:,1), [0, 255, 0; 255, 237, 255; 0, 255, 0]);
 assert(A(:,:,2), [0, 255, 0; 255,  28, 255; 0, 255, 0]);
 assert(A(:,:,3), [0, 255, 0; 255,  36, 255; 0, 255, 0]);
!!!!! test failed
imread: invalid image file: `__magick_read__' undefined near line 57 column
31>>>>> processing /home/thorsten/hg/octave/scripts/image/imshow.m

Trying on the command line, I find that indeed the commands __magick_finfo__,
__magick_write__ and __magick_read__ are unknown to the interpreter. Only the
autocompletion of readline knows them.

I have seen this problem since the imread test was added in changeset
ab563d2adc10. It persists even after a full make clean, autogen, configure, make
cycle.

Thorsten