http://www.perlmonks.org?node_id=674308


in reply to RFC: Setting up a minGW compiling envronment for Perl 5.10

I've gotten this to work with Perl 5.8, and I just (5 minutes ago) finished a basic Cairo/Glib/Gtk2 Perl stack for Perl 5.10.0.

My setup:

The order of building is Perl, Cairo, Glib, and then Gtk2. My notes from this latest build are posted here:

http://wiki.antlinux.com/pmwiki.php?n=CamelBox.Feb2008Start

It's 4 pages in sequence (follow the links at the bottom of the page to navigate). I have not updated the "Extra GTK Apps" page yet, but I don't expect any surprises. I don't know where you're at in your build (sounds like you got Cairo and Glib working, but not Gtk2), so maybe this will help you. If you do use my notes, at the very minimum, you'll have to change anything with a path of C:\camelbox to C:\strawberry, but I think that's about all you would need to do. For your Windows GTK libraries, are you also getting all of the support libraries that the GTK libraries are compiled against? The GTK libraries I used are on this page:

http://www.gtk.org/download-windows.html

I have all of the Binaries/dev packages under the GTK+ section, as well as all of the "Third Party Dependencies" that are marked with a checkbox image on the right hand side of that table.

I don't even bother with running the tests, I'm on the gtk-perl mailing list and the developers have acknowledged that the tests *will* fail under Windows. But I can still get a working and current Gtk2-Perl stack on Windows, so I'm happy.

PM/post here if you need any pointers.

Thanks,

Brian

P.S. My demo app (outside of the Gtk2-Perl demos that come with the Gtk2-Perl source):

http://cvs.antlinux.com/cvsweb.cgi/perl_scripts/gyroscope.pl... a web color-picker :)

Replies are listed 'Best First'.
Re^2: RFC: Setting up a minGW compiling envronment for Perl 5.10
by syphilis (Archbishop) on Mar 15, 2008 at 09:14 UTC
    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
[reply]
[d/l]
[reply]
[d/l]
[select]
        Try adding the ld option -export-all-symbols

        As regards my simplistic test case where I have Foo, Bar, and FooBar modules (and where FooBar needs to link to Foo.dll and Bar.dll), both Foo.dll and Bar.dll already export the symbols ('foo' and 'bar', respectively) that FooBar needs to link to.

        Having installed Foo and Bar into C:/temp/perl, I can try to build FooBar in the following way:

        1)Run 'perl Makefile.PL';
        2) Open the generated Makefile and, to the LDLOADLIBS entry, append -LC:/temp/perl/lib/auto/Bar -lBar -LC:/temp/perl/lib/auto/Foo -lFoo;

        Running dmake then terminates with: 
        FooBar.o:FooBar.c:(.text+0x1d): undefined reference to `foo'
collect2: ld returned 1 exit status
dmake:  Error code 129, while making 'blib\arch\auto\FooBar\FooBar.dll
+'

        [download]
        If, in step 2) I instead reverse the order and append -LC:/temp/perl/lib/auto/Foo -lFoo -LC:/temp/perl/lib/auto/Bar -lBar to the LDLOADLIBS entry in the generated Makefile, then dmake terminates with: 
        FooBar.o:FooBar.c:(.text+0x2b): undefined reference to `bar'
collect2: ld returned 1 exit status
dmake:  Error code 129, while making 'blib\arch\auto\FooBar\FooBar.dll
+'

        [download]
        If I don't do *anything* to the generated Makefile, dmake terminates with: 
        FooBar.o:FooBar.c:(.text+0x1d): undefined reference to `foo'
FooBar.o:FooBar.c:(.text+0x2b): undefined reference to `bar'
collect2: ld returned 1 exit status
dmake:  Error code 129, while making 'blib\arch\auto\FooBar\FooBar.dll
+'

        [download]
        I suspect that your suggestion of adding -export-all-symbols relates to the situation where Foo.dll and Bar.dll don't already export their symbols. In my case, both Foo.dll and Bar.dll already export their symbols, so I don't see that -export-all-symbols has anything to offer. (I know I don't have to ask you to correct me if I've missed the point :-)

        (This goes back to this thread - where, as you probably recall, you provided excellent help.)

        Hidden in readmore tags, below my sig, is the source to all three (Foo, Bar and FooBar) extensions ... for any who feel driven to test things out. It amazes me that Gtk2 resorts to this sort of thing ... I'm sure there are reasons for doing that ... as to whether they are *good* reasons ....

        Cheers,
        Rob
        Read more... (4 kB)
[reply]
[d/l]
[select]

In Section Meditations