Doug Hunt writes:
> Hi all: I just checked out rel_2_4_3rc1 and
> tested it on linux fedora core 3 for both i386
> (Intel 32 bit) and x86_64 (AMD 64 bit).
>
> On i386, I had a problem with openGL:
>----------%<----------------------------
> [EMAIL PROTECTED] PDLrc1]$ prove -v t/opengl.t
> t/opengl....1..3
> # Running under perl version 5.008007 for linux
> # Current time local: Wed Aug 9 15:58:56 2006
> # Current time GMT: Wed Aug 9 21:58:56 2006
> # Using Test.pm version 1.25
> ok 1
> Xlib: extension "GLX" missing on display "localhost:15.0".
> Could not create OpenGL window at
> /ops/tools/lib/perl5/site_perl/5.8.7/i686-linux-thread-multi/PDL/Graphics/OpenGL.pm
> line 3533.
> ERROR: failed to get an X visual
> dubious
> Test returned status 255 (wstat 65280, 0xff00)
> DIED. FAILED tests 2-3
> Failed 2/3 tests, 33.33% okay
> Failed Test Stat Wstat Total Fail Failed List of Failed
> -------------------------------------------------------------------------------
> t/opengl.t 255 65280 3 4 133.33% 2-3
> Failed 1/1 test scripts, 0.00% okay. 2/3 subtests failed, 33.33% okay.
> ---------------------------%<--------------------------------------------
>
> I know my DISPLAY was set correctly and X apps
> were working. I imagine that more fiddling
> with my FC3 install would yield the correct
> libraries, but it still seems that openGL
> detection is messed up. I ended up turning off
> WITH_3D and everything worked after that. I
> would recommend that being the default.
Would you try glxinfo on that display with
the failure so we could see what the opengl
hardware/driver setup is? It is possible that
the module built and would work ok but that
the display setup is preventing the test from
operating.
Did you try running the test by hand with the old
perl -Mblib t/opengl.t ? Sometimes the messages
there are more informative.
Are you running hardware OpenGL or Mesa?
Did the opengl work on x86_64?
It might be more useful to have the test fail
gracefully (skip all subtests) in the case
of a configuration error that prevents the
test from executing correctly. Don't know
if that is the case here but it is quite
possible that the module built ok and the
initial set-up was botched somehow. Maybe
something the test could be smarter about
but difficult to diagnose without users.
> For x86_64, things were less good.
>
> First of all, I had to change both
> Makefile.PL and Lib/Slatec/Makefile.PL by swapping
>
> $ENV{HOSTTYPE}=~m/x86_64/
> for
> $Config{archname}=~m/x86_64/
>
> for setting the -fPIC compiler flag to get it to
> compile. I would recommend making this change
> because $ENV{HOSTTYPE} behaves differently under
> different shells and circumstances--it is just
> cleaner to use $Config.
>
> I'll check this change in if there are no objections.
Sounds good here. I'll trust your experience. Don't have
AMD64 system here...at least not yet.
> Once it compiled, I still have problems with flexraw:
> ---------------------------%<---------------------------------
> [EMAIL PROTECTED] PDLrc1]$ prove -v t/flexraw.t
> t/flexraw....1..29
> Loaded ExtUtils::F77 version 1.14
> Found compiler g77
> ExtUtils::F77: Using system=Linux compiler=G77
> Checking for gcc in disguise:
> Compiler is gcc version 3.4.4 20050721 (Red Hat 3.4.4-2)
> Runtime: -L/usr/lib/gcc/x86_64-redhat-linux/3.4.4 -L/usr/lib -lg2c -lm
> -L/usr/lib/gcc/x86_64-redhat-linux/3.4.4 -lgcc
> ExtUtils::F77: Validating -L/usr/lib/gcc/x86_64-redhat-linux/3.4.4
> -L/usr/lib -lg2c -lm -L/usr/lib/gcc/x86_64-redhat-linux/3.4.4 -lgcc [ok]
> ExtUtils::F77: Compiler: g77
> ExtUtils::F77: Cflags: -O
> Error: Doesn't look like f77 file (even swapped) at
> /ops/tools/lib/perl5/site_perl/5.8.7/x86_64-linux-thread-multi/PDL/IO/FlexRaw.pm
> line 468
> # Looks like your test died before it could output anything.
> dubious
> Test returned status 9 (wstat 2304, 0x900)
> DIED. FAILED tests 1-29
> Failed 29/29 tests, 0.00% okay
> ---------------------------%<---------------------------------
It looks like flexraw as currently written might well be named
flexraw32 for the f77 32bit data structure format that is used
and assumed. I think for the point release, a skip all escape
for 64bit archs is the way to go.
> and slatec:
>
> ---------------------------%<---------------------------------
> [EMAIL PROTECTED] PDLrc1]$ prove -v t/slatec.t
> t/slatec....1..37
>
> ...removed some stuff...
>
>
> not ok 37
> int=[-1.0842e-19 2]; ans=[ 219.50999 100.13999]; int-ans=[-219.50999
> -98.139991]
> ref ans=PDL
> DUMPING 0xb91d10 datatype: 6
> State: (129) ALLOCATED|MYDIMS_TRANS
> transvtable: 0x0, trans: 0x0, sv: 0xb789c0
> Data SV: 0xb78a90, Svlen: 8, data: 0xb93bd0, nvals: 1
> Dims: 0xb91dd4 ()
> ThreadIds: 0xb91e04 (0)
> First values: (-2.000000)
> CHILDREN:
> DUMPING 0xb93470 datatype: 6
> State: (129) ALLOCATED|MYDIMS_TRANS
> transvtable: 0x0, trans: 0x0, sv: 0xb816f0
> Data SV: 0xb789e0, Svlen: 8, data: 0xb935d0, nvals: 1
> Dims: 0xb93534 ()
> ThreadIds: 0xb93564 (0)
> First values: (-0.500000)
> CHILDREN:
> FAILED test 37
> Failed 1/37 tests, 97.30% okay
> Failed Test Stat Wstat Total Fail Failed List of Failed
> ---------------------------%<---------------------------------
The test that fails starts with single precision
data which then calls the single precision pchia()
routing in slatec. Try setting the input PDL to
type double and see if you can run successfully
then, i.e.
In t/slatec.t:
line254 ## Test: chia
line255 #
line256 $x = double( sequence(11) - 0.3 );
That would be a work-around I could live with
until a more thorough exam of the problem can be
made.
> So it looks like we still have some 64 bit issues.
> Regards,
> Doug Hunt
Thanks for the testing! --Chris
> On Wed, 9 Aug 2006, Chris Marshall wrote:
>
> > I think that most major outstanding-but-fixable bugs
> > in the rel_2_4_3rc1 branch of cvs (a.k.a. release candidate
> > 1 for PDL-2.4.3). However, we have not seen tests for
> > the following platforms:
> >
> > MacOS 10.5 and 10.6: also, is the TriD build still broken if
> > you force it to happen in perldl.conf?
> >
> > AMD64 hardware: does the 64bit library get found?
> >
> > IRIX: does it build?
> >
> > AIX: does it build?
> >
> > I'll hold for the rest of this week pending further testing
> > as well as specific corrections and additions to the list of
> > known problems (included below for your reference and
> > immediate feedback if desired :-).
> >
> > If no further testers respond with issues then I'll move
> > to a final release candidate next Monday, verification
> > testing for a few days and a sf/cpan release by the end
> > of next week.
> >
> > Thanks all,
> > Chris
_______________________________________________
Perldl mailing list
[email protected]
http://mailman.jach.hawaii.edu/mailman/listinfo/perldl
