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.
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.
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
---------------------------%<---------------------------------
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
---------------------------%<---------------------------------
So it looks like we still have some 64 bit issues.
Regards,
Doug Hunt
[EMAIL PROTECTED]
Software Engineer III
UCAR - COSMIC, Tel. (303) 497-2611
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
Draft 2 of Known_problems:
=====================
The following issues have been reported with this version of
PDL:
- FFTW 3.0.1 is now out but is not supported (yet). You can use 2.x versions
of FFTW, fall back on the built-in fft routines, or (best of all) submit a
patch.
- Overly verbose but not particularly helpful text output from configure,
built, test process. This is especially confusing for beginning users.
- Compiler warnings from external code interfaces for several modules
including for the following files: PLplot.xs, GD.xs, GD.c, INTERP.xs,
RNG.xs, and RNG.c.
? Modern versions of MakeMaker (e.g. 6.22) fail to compile PDL, apparently
? because of the removal of the magic pm_to_blib target. Current
? versions (such as 6.17, bundled with the current perl, v5.8.6) work OK.
? With PDL 2.4.2, we have followed the core perl team in our use of
? earlier MakeMaker versions.
? If @INC has '.' at the front of the search path part of the build will
? fail (specifically mkpdlconv will not be able to 'use English' since
? it uses Exporter.pm from Basic/Core and not the system Exporter.pm).
? [added by Tim Jenness on 15 Apr 2000]
? [This appears to be fixed but this note is left FYI for the 2.4.2 release
-- CED 16-Dec-2004 ]
? PDL::Graphics::TriD doesn't seem to link correctly on the Mac, under
? MacOS 10.5 & 10.6. It has not been fixed in part because TriD needs an
? overhaul anyway, and in part because the code is cryptic. If you'd like
? to fix it, please do! Patches welcome. (PDL::Graphics::TriD is disabled
? by default on Mac installs, thanks, Doug)
? The t/fits.t test and PDL::IO::FITS module can show problems when
? used with old versions of the Astro::FITS::Header module. If you have
? problems then please install the latest version from
?
? http://search.cpan.org/~aallan/Astro-FITS-Header/
?
? (it is v2.8.1 at the time of writing) and see if this stops the problems.
? Note that Astro::FITS::Header has a somewhat esoteric numbering scheme
? (all the individual components have their own version number) which can
? make it hard to work out what version of the package have installed.
? SourceForge bugs as follows:
?
? 1530666 bugs in Transform.pm
? 1505171 failure in MatrixOps::eigens in CVS
? 1476324 How to force a completely clean installation
? 1465864 limits_round.t test failure
? 1465603 flexraw fails on Intel OS X with gfortran
? 1465414 Need lib64 version in various lib search paths for AMD64
? 1435189 Installation with cpan2rpm
? 1339530 pdlcore.c fails to build on IRIX and AIX
? 1205359 PGPLOT Window does not store full state info
For more information on these and other PDL issues, and for
submissions of patches (bug patches are always welcome!),
see the PDL mailing lists at http://pdl.perl.org/support.html
_______________________________________________
Perldl mailing list
[email protected]
http://mailman.jach.hawaii.edu/mailman/listinfo/perldl
