weird problem with __magick_read__.oct

[John W. Eaton-3]

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} {@var{m} =} __magick_read__(@var{fname}, @var{index})\n\
 @deftypefnx{Function File} {[@var{m}, @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

[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} {@var{m} =} __magick_read__(@var{fname}, @var{index})\n\
>  @deftypefnx{Function File} {[@var{m}, @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

[Jaroslav Hajek-2]

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

[Andy1978]

John W. Eaton-3 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
....
Can anyone else reproduce this problem?
jwe

I have exactly the same problem with the latest development sources 3.1.55
debian sid Linux version 2.6.26-1-686 (Debian 2.6.26-13lenny2) ([e-mail]) (gcc version 4.1.3 20080704 (prerelease) (Debian 4.1.2-25)) #1 SMP Fri Mar 13 18:08:45 UTC 2009
GraphicsMagick-config --version: 1.3.5
gcc -v: gcc version 4.3.3 (Debian 4.3.3-13)

How can I help to track down the problem?
Andy

[John W. Eaton-3]

On  5-Jul-2009, Andy1978 wrote:

| John W. Eaton-3 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
| > ....
| > Can anyone else reproduce this problem?
| > jwe
| >
|
| I have exactly the same problem with the latest development sources 3.1.55
| debian sid Linux version 2.6.26-1-686 (Debian 2.6.26-13lenny2)
| (dannf@...) (gcc version 4.1.3 20080704 (prerelease) (Debian
| 4.1.2-25)) #1 SMP Fri Mar 13 18:08:45 UTC 2009
| GraphicsMagick-config --version: 1.3.5
| gcc -v: gcc version 4.3.3 (Debian 4.3.3-13)
|
| How can I help to track down the problem?

If you can find out why dlopen/dlsym fails to find the function if it
is named __magick_read__ but succeeds if the name is something else,
then that might be a start.

jwe

[John W. Eaton-3]

On 15-Jul-2009, John W. Eaton wrote:

| On  5-Jul-2009, Andy1978 wrote:
|
| | John W. Eaton-3 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
| | > ....
| | > Can anyone else reproduce this problem?
| | > jwe
| | >
| |
| | I have exactly the same problem with the latest development sources 3.1.55
| | debian sid Linux version 2.6.26-1-686 (Debian 2.6.26-13lenny2)
| | (dannf@...) (gcc version 4.1.3 20080704 (prerelease) (Debian
| | 4.1.2-25)) #1 SMP Fri Mar 13 18:08:45 UTC 2009
| | GraphicsMagick-config --version: 1.3.5
| | gcc -v: gcc version 4.3.3 (Debian 4.3.3-13)
| |
| | How can I help to track down the problem?
|
| If you can find out why dlopen/dlsym fails to find the function if it
| is named __magick_read__ but succeeds if the name is something else,
| then that might be a start.

This was probably bad advice, as I seem to have misremembered the
symptoms.  Anyway, please try the following change:

  http://hg.savannah.gnu.org/hgweb/octave/rev/db08c2376970

It seems that the --ldflags option for Magick++-config produces

  -L/usr/lib -Wl,-z,relro -pie -L/usr/lib/X11 -L/usr/lib -L/usr/lib

on my system.  Passing "-pie" to g++ was apparently the problem.

jwe

[Jaroslav Hajek-2]

On Thu, Jul 16, 2009 at 8:16 PM, John W. Eaton<jwe@...> wrote:

> On 15-Jul-2009, John W. Eaton wrote:
>
> | On  5-Jul-2009, Andy1978 wrote:
> |
> | | John W. Eaton-3 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
> | | > ....
> | | > Can anyone else reproduce this problem?
> | | > jwe
> | | >
> | |
> | | I have exactly the same problem with the latest development sources 3.1.55
> | | debian sid Linux version 2.6.26-1-686 (Debian 2.6.26-13lenny2)
> | | (dannf@...) (gcc version 4.1.3 20080704 (prerelease) (Debian
> | | 4.1.2-25)) #1 SMP Fri Mar 13 18:08:45 UTC 2009
> | | GraphicsMagick-config --version: 1.3.5
> | | gcc -v: gcc version 4.3.3 (Debian 4.3.3-13)
> | |
> | | How can I help to track down the problem?
> |
> | If you can find out why dlopen/dlsym fails to find the function if it
> | is named __magick_read__ but succeeds if the name is something else,
> | then that might be a start.
>
> This was probably bad advice, as I seem to have misremembered the
> symptoms.  Anyway, please try the following change:
>
>  http://hg.savannah.gnu.org/hgweb/octave/rev/db08c2376970
>
> It seems that the --ldflags option for Magick++-config produces
>
>  -L/usr/lib -Wl,-z,relro -pie -L/usr/lib/X11 -L/usr/lib -L/usr/lib
>
> on my system.  Passing "-pie" to g++ was apparently the problem.
>
> jwe
>

Applied to 3.2.x.

regards

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

[Thomas Weber-8]

On Sat, Jul 25, 2009 at 04:17:04PM +0200, Jaroslav Hajek wrote:

> On Thu, Jul 16, 2009 at 8:16 PM, John W. Eaton<jwe@...> wrote:
> > On 15-Jul-2009, John W. Eaton wrote:
> > This was probably bad advice, as I seem to have misremembered the
> > symptoms.  Anyway, please try the following change:
> >
> >  http://hg.savannah.gnu.org/hgweb/octave/rev/db08c2376970
> >
> > It seems that the --ldflags option for Magick++-config produces
> >
> >  -L/usr/lib -Wl,-z,relro -pie -L/usr/lib/X11 -L/usr/lib -L/usr/lib
> >
> > on my system.  Passing "-pie" to g++ was apparently the problem.
> >
> > jwe
> >
>
> Applied to 3.2.x.

It doesn't seem to have been pushed to the release-3.2.x repository.

        Thomas

[Jaroslav Hajek-2]

On Sun, Jul 26, 2009 at 3:44 PM, Thomas
Weber<thomas.weber.mail@...> wrote:

> On Sat, Jul 25, 2009 at 04:17:04PM +0200, Jaroslav Hajek wrote:
>> On Thu, Jul 16, 2009 at 8:16 PM, John W. Eaton<jwe@...> wrote:
>> > On 15-Jul-2009, John W. Eaton wrote:
>> > This was probably bad advice, as I seem to have misremembered the
>> > symptoms.  Anyway, please try the following change:
>> >
>> >  http://hg.savannah.gnu.org/hgweb/octave/rev/db08c2376970
>> >
>> > It seems that the --ldflags option for Magick++-config produces
>> >
>> >  -L/usr/lib -Wl,-z,relro -pie -L/usr/lib/X11 -L/usr/lib -L/usr/lib
>> >
>> > on my system.  Passing "-pie" to g++ was apparently the problem.
>> >
>> > jwe
>> >
>>
>> Applied to 3.2.x.
>
> It doesn't seem to have been pushed to the release-3.2.x repository.
>
>        Thomas
>

It is now, sorry.


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

[Thomas Weber-8]

On Sun, Jul 26, 2009 at 09:26:09PM +0200, Jaroslav Hajek wrote:

> On Sun, Jul 26, 2009 at 3:44 PM, Thomas
> Weber<thomas.weber.mail@...> wrote:
> > On Sat, Jul 25, 2009 at 04:17:04PM +0200, Jaroslav Hajek wrote:
> >> On Thu, Jul 16, 2009 at 8:16 PM, John W. Eaton<jwe@...> wrote:
> >> > On 15-Jul-2009, John W. Eaton wrote:
> >> > This was probably bad advice, as I seem to have misremembered the
> >> > symptoms.  Anyway, please try the following change:
> >> >
> >> >  http://hg.savannah.gnu.org/hgweb/octave/rev/db08c2376970
> >> >
> >> > It seems that the --ldflags option for Magick++-config produces
> >> >
> >> >  -L/usr/lib -Wl,-z,relro -pie -L/usr/lib/X11 -L/usr/lib -L/usr/lib
> >> >
> >> > on my system.  Passing "-pie" to g++ was apparently the problem.
> >> >
> >> > jwe
> >> >
> >>
> >> Applied to 3.2.x.
> >
> > It doesn't seem to have been pushed to the release-3.2.x repository.
> >
> >        Thomas
> >
>
> It is now, sorry.

No problem :)

Thanks
        Thomas