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
