laziness, impatience, and hubris | |
PerlMonks |
comment on |
( [id://3333]=superdoc: print w/replies, xml ) | Need Help?? |
... 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.) Cheers, Rob In reply to Re^2: RFC: Setting up a minGW compiling envronment for Perl 5.10
by syphilis
|
|