laziness, impatience, and hubris | |
PerlMonks |
Re^2: RFC: Setting up a minGW compiling envronment for Perl 5.10by syphilis (Archbishop) |
on Mar 15, 2008 at 09:14 UTC ( [id://674345]=note: print w/replies, xml ) | Need Help?? |
I'm on the gtk-perl mailing list and the developers have acknowledged that the tests *will* fail under Windows IIRC a number of the tests fail with errors along the lines of (eg, from gdk.t) Can't locate object method "get_xid" via package "Gtk2::Gdk::Window" at t/gdk.t line 108. Is that *really* a Windows-only error ? I also think that having pkg-config and glib be mutually dependent (but separate) is bad software design ... though really brilliant April Fool's Day prank design. And I feel the same away about the need for Gtk2 to link to the auto/Cairo/Cairo.dll and auto/Glib/Glib.dll. I have a question for you. I found I was able to link directly to either auto/Cairo/Cairo.dll or auto/Glib/Glib.dll ... but not both. Do you know why that is ? Presumably, it's a perl quirk/bug, since, if I build a C application using MinGW's gcc, I can link directly to as many dll's as is needed. But with the perl dll's, it seems that *one* is the limit. I even went to the trouble of building a Foo module and a FooBar module - where FooBar had to link directly to the Foo.dll. And that worked fine. I then built a Bar module, and changed FooBar so that it needed to link directly to both Foo.dll and Bar.dll. It couldn't do that - I could get it to link to one or the other, but not both. So I created import libs (which I think is what you have done, too) and linking to them worked fine. I still don't see why linking to *more than one* dll should fail. Cheers, Rob
In Section
Meditations
|
|