Re: GtkImageView

[muppet <scott asofyet org>]

On Dec 6, 2007, at 1:19 AM, Jeffrey Ratcliffe wrote:

> On 05/12/2007, BJörn Lindqvist <bjourne gmail com> wrote:
> > It is true that the enumeration GTypes probably should be declared in
> > the C library, although it is not strictly necessary AFAIK. Take a
> > look at how PyGtkImageView gets around it in
> > http://trac.bjourne.webfactional.com/browser/pygtkimageview/src/Makefile.am 
> > .
> > I think a similar workaround should be possible for the Perl  
> > bindings.
>
> But as far as I can see, he has simply the .h, as I do, and his
> corresponding .c is what you said should go in the .xs (thanks).

This is true, the C library is not required to provide a GType for the  
enumeration.  However, without a GType for the enumeration, the  
enumeration cannot be used in any object properties or signal  
arguments; it would have to be passed as an integer, because the type  
system doesn't know about it.  This would then require you to write  
icky, hard-to-maintain, special-case marshalers for all these things  
if you want to use the enumerations in perl.

So, yes, the upstream library doesn't *need* to provide the  
enumeration GType, but it saves everybody else work if it does.  Also,  
if and when he does add this upstream, you'll have to change your  
bindings to retain compatibility.



> /home/jeff/perl/Gtk2-ImageView/blib/arch/auto/Gtk2/ImageView/ 
> ImageView.so:
> undefined symbol: SvGtkImageTransp at
> /usr/lib/perl5/5.8.5/i386-linux-thread-multi/DynaLoader.pm line 230.
>
> I don't understand why I only get the above error with make test.

The unit tests run with LD_BIND_NOW.  This causes the dynamic linker  
to avoid its default behavior of "lazy" evaluation,  which is looking  
up the symbols on the first call, and instead causes the program to  
attempt to resolve all dynamic symbols at startup.  So, the function  
really isn't there, and the unit tests are finding this for you.   
Clearly, your standalone script never tries to call the function.

Now, the SvGTypeName symbols are typically does as macros, not  
functions.  In fact, your earlier email showed this symbol defined as  
a macro.   This all suggests that the compiler is not seeing the  
SvGtkImageTransp macro and is instead trying to call it as an  
undefined function.  Do you see any compiler warnings to this effect  
when building the extension?  Are you including the header that  
defines this macro in your .xs file?



--
The one difference between Dali and a crazy man is very simple: Dali  
is not crazy at all.
  -- Salvador Dali