Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl: the Markov chain saw

Re: RFC: Setting up a minGW compiling envronment for Perl 5.10

by Bloodrage (Monk)
on Mar 03, 2008 at 23:10 UTC ( #671736=note: print w/replies, xml ) Need Help??

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

Righty I now have Glib and cairo compiled (though they might not be entirely reliable... due to failed tests... or the tests don't work appropriatly on Windows) and installed. Onto Gtk2.

Firstly, it needs to see it's own build directory added to it's INC entry in the Makefile... repeat for gperl.h, gtk2-perl-versions.h, and cairo-perl.h adding their own paths to INC of course.

Then we get more undefined reference to errors, time to check the libraries... using the method described earlier.

The only library passed to the Makefile by Makefile.PL and MakeMaker that I could not locate was gdk_pixbuf-2.0.a... part of the GNOME Imaging Model, ...morelikely it's because I haven't copied the new entries from EXTRALIBS into LOADLIBS :P

Righty still getting undefined reference to errors, there's also this comment here which makes me think I need to figure out how to get the Makefile to link to Glib.dll.

...but for now I need to be brave and reinstall Windows XP on Her computer because it's being wierd.

1 I just searched for "INC ="

Replies are listed 'Best First'.
Re^2: RFC: Setting up a minGW compiling envronment for Perl 5.10
by syphilis (Chancellor) on Mar 04, 2008 at 17:59 UTC
    ... or the tests don't work appropriatly on Windows

    I think that's the case. I'm finding that many of the t/64bit.t tests fail - evidently the 64-bit support (which is expected to be in existence) is missing on Win32. I haven't investigated.
    Also test 14 of t/9.t hangs. All of the other tests in t/9.t pass.
    There are some tests in t/filename.t (and one test in t/g.t) that fail simply because backslashes appear in the path instead of the expected forward slashes. (These failures are inconsequential and can be ignored.)

    I need to figure out how to get the Makefile to link to Glib.dll

    Yes - that seems to be the case. But then there's also the need to link to Cairo.dll as well.

    To EXTRALIBS and LDLOADLIBS in the generated Makefile, I added (before running 'dmake'):
    (which is the location of Glib.dll on my perl) and that takes care of the gperl_* references ... but there's still the cairo_* references to attend to. If I also add (to EXTRALIBS and LDLOADLIBS):
    it doesn't help (unless that's inserted *before* the Glib.dll entry - in which case we've fixed the cairo_* references, but not the gperl_* references). That is, using this hack, we can fix either the cairo_* references or the gperl_* references ... but not both. I don't know why that is - and I haven't yet worked out a hack to fix it. I'm still puzzling over it - and will try to come up with something tomorrow. (Better still if someone can beat me to it.)


      oooh, um what about I:\GTK\lib\libglib-2.0.dll.a and I:\GTK\lib\libcairo-2.0.dll.a? Are these the libraries we're looking for?

      Can't check it here, this PC lacking in CPU... and I'd have to completely rebuild my Makefile.

        Are these the libraries we're looking for?

        Unfortunately no. They are just the import libs. Instead of renaming the .lib files to .a files, you could have renamed the .dll.a files to .a files. That's what I did to get Glib and Cairo to build (and they built straight out of the box for me with 'perl', 'dmake test', and 'dmake install'). Had I have known that those .dll.a files were there I would have suggested you rename them instead of the .lib files - but it shouldn't matter anyway.

        Gtk2 is doing something that I've not come across before - and I hope I never come across it again. Some of its XSubs use XSubs that are part of the Glib and Cairo modules - and the only way to resolve the definition of those functions (that I can see) is to link to auto/Glib/Glib.dll and auto/Cairo/Cairo.dll.

        Maybe we have to go the -LC:/perl/site/lib/auto/Glib -lGlib, but I've gotta check that the -lGlib is, in fact, capable of linking to Glib.dll. (I think it should be, but I've gotta check on it - maybe you could give it a try, anyway.)

        I've also yet to see if Mr.Google can shed some light on how to fix this problem. And there's probably a gtk/glib mailing list if all else fails.


Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://671736]
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others imbibing at the Monastery: (4)
As of 2018-06-19 01:56 GMT
Find Nodes?
    Voting Booth?
    Should cpanminus be part of the standard Perl release?

    Results (111 votes). Check out past polls.