Skip Menu |

Preferred bug tracker

Please visit the preferred bug tracker to report your issue.

This queue is for tickets about the PDL CPAN distribution.

Report information
The Basics
Id: 21407
Status: resolved
Priority: 0/
Queue: PDL
People
Owner: Nobody in particular
Requestors: SREZIC [...] cpan.org
Cc: chm [...] cpan.org
AdminCc:
Bug Information
Severity: Critical
Broken in:
  • 2.4.3
  • 2.4.2
Fixed in: 2.4.4
Attachments
build-with-bsd-make.txt
build-with-gnu-make.txt
dumper.log
pdl-2.4.3-freebsd-fix.patch
PDL.yml

History Show all quoted text
  Sat Sep 09 15:35:38 2006 SREZIC [...] cpan.org - Ticket created
Subject: Build failed due to missing pptemplate
Building PDL under FreeBSD 6.1 with perl 5.8.8 failed on my machine: $ make Graph cycles through pm_to_blib cp Reduce.pm ../blib/lib/PDL/Reduce.pm cp PDL.pm ../blib/lib/PDL.pm cp Lite.pm ../blib/lib/PDL/Lite.pm cp Options.pm ../blib/lib/PDL/Options.pm cp LiteF.pm ../blib/lib/PDL/LiteF.pm cp default.perldlrc ../blib/lib/PDL/default.perldlrc cp AutoLoader.pm ../blib/lib/PDL/AutoLoader.pm cp Lvalue.pm ../blib/lib/PDL/Lvalue.pm cp Matrix.pm ../blib/lib/PDL/Matrix.pm podselect ../Gen/Inline/Pdlpp.pm > PP-Inline.pod cp BadValues.pod ../../blib/lib/PDL/BadValues.pod cp Impatient.pod ../../blib/lib/PDL/Impatient.pod cp Internals.pod ../../blib/lib/PDL/Internals.pod cp Tips.pod ../../blib/lib/PDL/Tips.pod cp PP-Inline.pod ../../blib/lib/PDL/PP-Inline.pod cp Dataflow.pod ../../blib/lib/PDL/Dataflow.pod cp Delta.pod ../../blib/lib/PDL/Delta.pod cp FAQ.pod ../../blib/lib/PDL/FAQ.pod cp Philosophy.pod ../../blib/lib/PDL/Philosophy.pod cp Indexing.pod ../../blib/lib/PDL/Indexing.pod cp Objects.pod ../../blib/lib/PDL/Objects.pod cp Intro.pod ../../blib/lib/PDL/Intro.pod cp PP.pod ../../blib/lib/PDL/PP.pod cp API.pod ../../blib/lib/PDL/API.pod Manifying ../../blib/man1/PDL::Impatient.1 Manifying ../../blib/man1/PDL::BadValues.1 Manifying ../../blib/man1/PDL::Internals.1 Manifying ../../blib/man1/PDL::PP-Inline.1 Manifying ../../blib/man1/PDL::Tips.1 Manifying ../../blib/man1/PDL::Dataflow.1 Manifying ../../blib/man1/PDL::Delta.1 Manifying ../../blib/man1/PDL::Philosophy.1 Manifying ../../blib/man1/PDL::FAQ.1 Manifying ../../blib/man1/PDL::Objects.1 Manifying ../../blib/man1/PDL::Indexing.1 Manifying ../../blib/man1/pdl.1 Manifying ../../blib/man1/PDL::PP.1 Manifying ../../blib/man1/PDL::API.1 /usr/local/bin/perl PP/dump.pp > PP/Dump.pm.tmp mv PP/Dump.pm.tmp PP/Dump.pm Graph cycles through pm_to_blib cp Pdlpp.pm ../../../blib/lib/Inline/Pdlpp.pm cp MakePdlppInstallable.pm ../../../blib/lib/Inline/MakePdlppInstallable.pm Manifying ../../../blib/man3/Pdlpp.3 cp pptemplate ../../blib/script/pptemplate cp: pptemplate: No such file or directory *** Error code 1 Stop in /usr/local/src/CPAN/build/PDL-2.4.3/Basic/Gen. *** Error code 1 Stop in /usr/local/src/CPAN/build/PDL-2.4.3/Basic. *** Error code 1 Stop in /usr/local/src/CPAN/build/PDL-2.4.3. Exitcode 1 Regards, Slaven
  Sat Sep 23 23:30:43 2006 chm [...] cpan.org - Cc CHM added
  Sat Sep 23 23:30:43 2006 chm [...] cpan.org - Correspondence added
Hi, I'm looking for more information on your build problem to diagnose. Could you please provide some additional information: 1. How did you attempt the build of PDL? cpan shell, manual download and build,... 2. What options did you use? the standard defaults? Did you edit the top level perldl.conf file? 3. Could you please attach the full output of the configure and compile process? To do this, you will need to drive the configure and build process by hand. One way is as follows: - download the PDL-2.4.3-tar.gz release and untar - cd to the resulting directory - perl Makefile.PL 2>&1 >pdl-build-log.txt - make 2>&1 >>pdl-build-log.txt ... If you modified the perldl.conf please report the changes you made. If you could attach the resulting pdl-build-log.txt to this ticket and the perldl.conf if needed, that will give a place to start looking. Thanks for the initial report. Look forward to hearing from you further. --Chris Marshall
  Sat Sep 23 23:30:44 2006 The RT System itself - Status changed from 'new' to 'open'
  Sun Sep 24 14:49:20 2006 slaven [...] rezic.de - Correspondence added
Subject: Re: [rt.cpan.org #21407] Build failed due to missing pptemplate
Date: 24 Sep 2006 20:39:19 +0200
To: bug-PDL [...] rt.cpan.org
From: Slaven Rezic <slaven [...] rezic.de>
"Christopher Marshall via RT" <bug-PDL@rt.cpan.org> writes: Show quoted text
> <URL: http://rt.cpan.org/Ticket/Display.html?id=21407 > > > Hi, I'm looking for more information on your build problem to > diagnose. Could you please provide some additional information: > > 1. How did you attempt the build of PDL? > cpan shell, manual download and build,...
I tried CPAN shell, but the manual build yields the same failure. Show quoted text
> > 2. What options did you use? > the standard defaults? > Did you edit the top level perldl.conf file?
It's just the standard defaults. Show quoted text
> > 3. Could you please attach the full output of the > configure and compile process? To do this, you > will need to drive the configure and build > process by hand. > > One way is as follows: > > - download the PDL-2.4.3-tar.gz release and untar > - cd to the resulting directory > - perl Makefile.PL 2>&1 >pdl-build-log.txt > - make 2>&1 >>pdl-build-log.txt > ...
See the attached "build-with-bsd-make.txt". If I use GNU make instead of the standard BSD make, then the build process goes much farther, but eventually fails with some OpenGL problem. See the attached "build-with-gnu-make.txt" for this attempt. Regards, Slaven

Message body is not shown because sender requested not to inline it.

Message body is not shown because sender requested not to inline it.

-- Slaven Rezic - slaven <at> rezic <dot> de tkruler - Perl/Tk program for measuring screen distances http://ptktools.sourceforge.net/#tkruler
  Sun Sep 24 16:40:55 2006 chm [...] cpan.org - Correspondence added
From: chm [...] alum.mit.edu
On 24-Sep-2006 Slaven wrote: Show quoted text
> > See the attached "build-with-bsd-make.txt". If I use GNU make instead > of the standard BSD make, then the build process goes much farther, > but eventually fails with some OpenGL problem. See the attached > "build-with-gnu-make.txt" for this attempt.
I took a look at the output from your build logs. As far as the pptemplate issue, it looks like a dependency issue with the make. You could attach the generated Makefile from the Basic/Gen subdirectory so we could see if the same build commands are being generated on BSD as on other OSes. The OpenGL problem appears to be that the required OpenGL and X header files are not in the OPENGL_INC path being checked (it looks like /usr/include from the output: ...WARNING: could not find file X.h in path '/usr/include'. ...WARNING: could not find file gl.h in path '/usr/include'. ...WARNING: could not find file glx.h in path '/usr/include'. ...WARNING: could not find file glu.h in path '/usr/include'. ...WARNING: could not find file glxtokens.h in path '/usr/include'. If you could determine the include directories where these files are for BSD, try to add them in the perldl.conf file in the OPENGL_INC parameter before another GNU make build: perl Makefile.PL 2>&1 >gmake-log.txt gmake 2>&1 >>gmake-log.txt Let me know how it goes. If it is a path issue, we can add it into the cvs tree for the next release. --Chris
  Mon Sep 25 10:08:08 2006 chm [...] cpan.org - Correspondence added
From: chm [...] alum.mit.edu
On Sun Sep 24 16:40:55 2006, CHM wrote: Show quoted text
> > I took a look at the output from your build logs. > > As far as the pptemplate issue, it looks like a dependency > issue with the make. You could attach the generated Makefile > from the Basic/Gen subdirectory so we could see if the same > build commands are being generated on BSD as on other OSes.
I did some more googling and discovered that this pmake problem has been reported before. Apparently it is a problem with the Makefile being generated by MakeMaker having a dependency graph which causes the pmake build to fail. I guess GNU make is more permissive and goes ahead with the build. What version of ExtUtils::MakeMaker are you running? Show quoted text
> > perl -MExtUtils::MakeMaker -e 'print $ExtUtils::MakeMaker::VERSION;'
Regards, Chris
  Mon Sep 25 10:10:15 2006 chm [...] cpan.org - Broken in 2.4.2 added
  Mon Sep 25 10:22:33 2006 chm [...] cpan.org - Correspondence added
From: chm [at] alum.mit.edu
Show quoted text
> > What version of ExtUtils::MakeMaker are you running?
> > > perl -MExtUtils::MakeMaker -e 'print $ExtUtils::MakeMaker::VERSION;'
>
ExtUtils::MakeMaker version 6.30 is out an its documentation suggests that it has fixed this problem. If it is possible, could you please test? If it works, we could close this item with the two options: GNU make as a work-around and EU:MM v6.30 as the real fix. --Chris
  Mon Sep 25 14:59:05 2006 slaven [...] rezic.de - Correspondence added
Subject: Re: [rt.cpan.org #21407] Build failed due to missing pptemplate
Date: 25 Sep 2006 20:56:22 +0200
To: bug-PDL [...] rt.cpan.org
From: Slaven Rezic <slaven [...] rezic.de>
"Christopher Marshall via RT" <bug-PDL@rt.cpan.org> writes: Show quoted text
> <URL: http://rt.cpan.org/Ticket/Display.html?id=21407 > > > On Sun Sep 24 16:40:55 2006, CHM wrote:
> > > > I took a look at the output from your build logs. > > > > As far as the pptemplate issue, it looks like a dependency > > issue with the make. You could attach the generated Makefile > > from the Basic/Gen subdirectory so we could see if the same > > build commands are being generated on BSD as on other OSes.
> > I did some more googling and discovered that this pmake > problem has been reported before. Apparently it is a > problem with the Makefile being generated by MakeMaker > having a dependency graph which causes the pmake build > to fail. I guess GNU make is more permissive and goes > ahead with the build. > > What version of ExtUtils::MakeMaker are you running?
> > > perl -MExtUtils::MakeMaker -e 'print $ExtUtils::MakeMaker::VERSION;'
>
It's 6.30. But note that there's a FreeBSD speciality called BSDPAN which introduces a module hooks into ExtUtils::MakeMaker::WriteMakefile. However it seems that this hook is largely a no-op unless a special environment variable is defined. Regards, Slaven -- Slaven Rezic - slaven <at> rezic <dot> de Tk-AppMaster: a perl/Tk module launcher designed for handhelds http://tk-appmaster.sf.net
  Mon Sep 25 15:09:12 2006 slaven [...] rezic.de - Correspondence added
CC: SREZIC [...] cpan.org
Subject: Re: [rt.cpan.org #21407] Build failed due to missing pptemplate
Date: 25 Sep 2006 21:08:30 +0200
To: bug-PDL [...] rt.cpan.org
From: Slaven Rezic <slaven [...] rezic.de>
"Christopher Marshall via RT" <bug-PDL@rt.cpan.org> writes: Show quoted text
> <URL: http://rt.cpan.org/Ticket/Display.html?id=21407 > > > On 24-Sep-2006 Slaven wrote:
> > > > See the attached "build-with-bsd-make.txt". If I use GNU make instead > > of the standard BSD make, then the build process goes much farther, > > but eventually fails with some OpenGL problem. See the attached > > "build-with-gnu-make.txt" for this attempt.
> > I took a look at the output from your build logs. > > As far as the pptemplate issue, it looks like a dependency > issue with the make. You could attach the generated Makefile > from the Basic/Gen subdirectory so we could see if the same > build commands are being generated on BSD as on other OSes.
Do you still need it? Show quoted text
> > The OpenGL problem appears to be that the required OpenGL and X > header files are not in the OPENGL_INC path being checked (it > looks like /usr/include from the output: > > ...WARNING: could not find file X.h in path '/usr/include'. > ...WARNING: could not find file gl.h in path '/usr/include'. > ...WARNING: could not find file glx.h in path '/usr/include'. > ...WARNING: could not find file glu.h in path '/usr/include'. > ...WARNING: could not find file glxtokens.h in path '/usr/include'. > > If you could determine the include directories where these > files are for BSD, try to add them in the perldl.conf file > in the OPENGL_INC parameter before another GNU make build: > > perl Makefile.PL 2>&1 >gmake-log.txt > gmake 2>&1 >>gmake-log.txt > > Let me know how it goes. If it is a path issue, we can add it > into the cvs tree for the next release. >
*BSD systems never install non-OS add-ons to /usr/include and /usr/lib. X11 stuff is usually in /usr/X11R6/include and /usr/X11R6/lib, and non-X11 stuff is usually in /usr/local/include and /usr/local/lib. It is also a good idea to add $Config{locincpth} to $Config{loclibpth} to -I and -L when compiling C code. Regards, Slaven -- Slaven Rezic - slaven <at> rezic <dot> de tknotes - A knotes clone, written in Perl/Tk. http://ptktools.sourceforge.net/#tknotes
  Mon Sep 25 15:09:14 2006 slaven [...] rezic.de - Correspondence added
CC: SREZIC [...] cpan.org
Subject: Re: [rt.cpan.org #21407] Build failed due to missing pptemplate
Date: 25 Sep 2006 21:03:51 +0200
To: bug-PDL [...] rt.cpan.org
From: Slaven Rezic <slaven [...] rezic.de>
"Christopher Marshall via RT" <bug-PDL@rt.cpan.org> writes: Show quoted text
> <URL: http://rt.cpan.org/Ticket/Display.html?id=21407 > >
> > > > What version of ExtUtils::MakeMaker are you running?
> > > > perl -MExtUtils::MakeMaker -e 'print $ExtUtils::MakeMaker::VERSION;'
> >
> > ExtUtils::MakeMaker version 6.30 is out an its documentation > suggests that it has fixed this problem. If it is possible, > could you please test? If it works, we could close this item > with the two options: GNU make as a work-around and EU:MM v6.30 > as the real fix.
No, 6.30 without BSDPAN does not solve the problem. And I just saw that the official FreeBSD port of PDL has USE_GMAKE= yes defined --- which helps users using the FreeBSD ports system, but not users who do a manual build or a build from CPAN.pm Regards, Slaven -- Slaven Rezic - slaven <at> rezic <dot> de BBBike - route planner for cyclists in Berlin WWW version: http://www.bbbike.de Perl/Tk version for Unix and Windows: http://bbbike.sourceforge.net
  Mon Sep 25 15:37:46 2006 chm [...] cpan.org - Correspondence added
From: chm[at] alum.mit.edu
On Mon Sep 25 15:09:12 2006, slaven@rezic.de wrote: Show quoted text
> "Chris Marshall via RT" <bug-PDL@rt.cpan.org> writes: >
> > <URL: http://rt.cpan.org/Ticket/Display.html?id=21407 > > > > > On 24-Sep-2006 Slaven wrote: > > ... > > > > As far as the pptemplate issue, it looks like a dependency > > issue with the make. You could attach the generated Makefile > > from the Basic/Gen subdirectory so we could see if the same > > build commands are being generated on BSD as on other OSes.
> > Do you still need it?
No, I believe we have determined the origin of the problem. It looks like it will take some make/MakeMaker debugging to proceed. We may have to settle for the GNU make work-around. Show quoted text
> > The OpenGL problem appears to be that the required OpenGL and X > > header files are not in the OPENGL_INC path being checked (it > > looks like /usr/include from the output: > > > > ...WARNING: could not find file X.h in path '/usr/include'. > > ...WARNING: could not find file gl.h in path '/usr/include'. > > ...WARNING: could not find file glx.h in path '/usr/include'. > > ...WARNING: could not find file glu.h in path '/usr/include'. > > ...WARNING: could not find file glxtokens.h in path '/usr/include'. > > > > If you could determine the include directories where these > > files are for BSD, try to add them in the perldl.conf file > > in the OPENGL_INC parameter before another GNU make build: > > > > perl Makefile.PL 2>&1 >gmake-log.txt > > gmake 2>&1 >>gmake-log.txt > > > > Let me know how it goes. If it is a path issue, we can add it > > into the cvs tree for the next release. > >
> > *BSD systems never install non-OS add-ons to /usr/include and > /usr/lib. X11 stuff is usually in /usr/X11R6/include and > /usr/X11R6/lib, and non-X11 stuff is usually in /usr/local/include and > /usr/local/lib. It is also a good idea to add $Config{locincpth} to > $Config{loclibpth} to -I and -L when compiling C code.
When you modified OPENGL_INC to include the locations for your system (e.g. $Config{locincpth}), did the PDL build complete (w GNU make)? The PDL::Graphics::TriD::OpenGL code is being refactored for the next major release of PDL. We'll try to improve the build process as well at that time. Before then, a quick 2.4.4 release to specifically fix known 2.4.3 release issues for the CPAN version is possible. We could include the any 2.4.3 build include path fixes then. Thanks for the suggestions and feedback. --Chris
  Mon Sep 25 16:00:56 2006 slaven [...] rezic.de - Correspondence added
CC: SREZIC [...] cpan.org
Subject: Re: [rt.cpan.org #21407] Build failed due to missing pptemplate
Date: 25 Sep 2006 21:53:55 +0200
To: bug-PDL [...] rt.cpan.org
From: Slaven Rezic <slaven [...] rezic.de>
"Christopher Marshall via RT" <bug-PDL@rt.cpan.org> writes: Show quoted text
> <URL: http://rt.cpan.org/Ticket/Display.html?id=21407 > > > On Mon Sep 25 15:09:12 2006, slaven@rezic.de wrote:
> > "Chris Marshall via RT" <bug-PDL@rt.cpan.org> writes: > >
> > > <URL: http://rt.cpan.org/Ticket/Display.html?id=21407 > > > > > > > On 24-Sep-2006 Slaven wrote: > > > ... > > > > > > As far as the pptemplate issue, it looks like a dependency > > > issue with the make. You could attach the generated Makefile > > > from the Basic/Gen subdirectory so we could see if the same > > > build commands are being generated on BSD as on other OSes.
> > > > Do you still need it?
> > No, I believe we have determined the origin of the problem. > It looks like it will take some make/MakeMaker debugging to > proceed. We may have to settle for the GNU make work-around. >
> > > The OpenGL problem appears to be that the required OpenGL and X > > > header files are not in the OPENGL_INC path being checked (it > > > looks like /usr/include from the output: > > > > > > ...WARNING: could not find file X.h in path '/usr/include'. > > > ...WARNING: could not find file gl.h in path '/usr/include'. > > > ...WARNING: could not find file glx.h in path '/usr/include'. > > > ...WARNING: could not find file glu.h in path '/usr/include'. > > > ...WARNING: could not find file glxtokens.h in path '/usr/include'. > > > > > > If you could determine the include directories where these > > > files are for BSD, try to add them in the perldl.conf file > > > in the OPENGL_INC parameter before another GNU make build: > > > > > > perl Makefile.PL 2>&1 >gmake-log.txt > > > gmake 2>&1 >>gmake-log.txt > > > > > > Let me know how it goes. If it is a path issue, we can add it > > > into the cvs tree for the next release. > > >
> > > > *BSD systems never install non-OS add-ons to /usr/include and > > /usr/lib. X11 stuff is usually in /usr/X11R6/include and > > /usr/X11R6/lib, and non-X11 stuff is usually in /usr/local/include and > > /usr/local/lib. It is also a good idea to add $Config{locincpth} to > > $Config{loclibpth} to -I and -L when compiling C code.
> > When you modified OPENGL_INC to include the locations for > your system (e.g. $Config{locincpth}), did the PDL build > complete (w GNU make)? The PDL::Graphics::TriD::OpenGL > code is being refactored for the next major release of PDL. > We'll try to improve the build process as well at that time.
It compiles if I set OPENGL_LIBS => "-L/usr/X11R6/lib", OPENGL_INC => "-I/usr/X11R6/include", in perldl.conf "gmake test" has only the following failures: t/dumper....................# Failed test 10 in t/dumper.t at line 70 # t/dumper.t line 70 is: ok(!$@); # Failed test 11 in t/dumper.t at line 84 # t/dumper.t line 84 is: ok((ref $a eq 'HASH')); # Failed test 12 in t/dumper.t at line 85 # t/dumper.t line 85 is: ok((ref $a->{e} eq 'PDL') # Failed test 14 in t/dumper.t at line 94 # t/dumper.t line 94 is: ok(!$@ && (ref $a eq 'ARRAY')); # Failed test 15 in t/dumper.t at line 96 # t/dumper.t line 96 is: ok(eval '$a->[0]->hdrcpy() == 1 && $a->[1]->hdrcpy() == 0'); # Failed test 16 in t/dumper.t at line 97 # t/dumper.t line 97 is: ok(eval '($a->[0]->gethdr()->{ok}==1) && ($a->[1]->gethdr()->{ok}==2)'); FAILED tests 10-12, 14-16 Failed 6/16 tests, 62.50% okay All other tests pass. Regards, Slaven -- Slaven Rezic - slaven <at> rezic <dot> de tkrevdiff - graphical display of diffs between revisions (RCS, CVS or SVN) http://ptktools.sourceforge.net/#tkrevdiff
  Mon Sep 25 17:40:21 2006 chm [...] cpan.org - Correspondence added
From: chm [at] alum.mit.edu
On Mon Sep 25 16:00:56 2006, slaven@rezic.de wrote: Show quoted text
> > > > When you modified OPENGL_INC to include the locations for > > your system (e.g. $Config{locincpth}), did the PDL build > > complete (w GNU make)? The PDL::Graphics::TriD::OpenGL > > code is being refactored for the next major release of PDL. > > We'll try to improve the build process as well at that time.
> > It compiles if I set > > OPENGL_LIBS => "-L/usr/X11R6/lib", > OPENGL_INC => "-I/usr/X11R6/include", > > in perldl.conf
Excellent! I'll be sure that those two directories are added to the appropriate config search paths. By the way, were these directories in your $Config{loclibpth} and $Config{locincpth}? Show quoted text
> "gmake test" has only the following failures: > > t/dumper....................# Failed test 10 in t/dumper.t at line 70 > # t/dumper.t line 70 is: ok(!$@); > # Failed test 11 in t/dumper.t at line 84 > # t/dumper.t line 84 is: ok((ref $a eq 'HASH')); > # Failed test 12 in t/dumper.t at line 85 > # t/dumper.t line 85 is: ok((ref $a->{e} eq 'PDL') > # Failed test 14 in t/dumper.t at line 94 > # t/dumper.t line 94 is: ok(!$@ && (ref $a eq 'ARRAY')); > # Failed test 15 in t/dumper.t at line 96 > # t/dumper.t line 96 is: ok(eval '$a->[0]->hdrcpy() == 1 && $a->[1]-
> >hdrcpy() == 0');
> # Failed test 16 in t/dumper.t at line 97 > # t/dumper.t line 97 is: ok(eval '($a->[0]->gethdr()->{ok}==1) && > ($a->[1]->gethdr()->{ok}==2)'); > FAILED tests 10-12, 14-16 > Failed 6/16 tests, 62.50% okay
Could try running the test by hand to see if there are any additional error messages? Try perl -Mblib t/dumper.t from the top level PDL-2.4.3 build directory. I took a quick look at the Dumper.pm code at the failed tests need uuencode and uudecode to function correctly? Are they available on your system and in your path? Regards, Chris
  Mon Sep 25 18:06:20 2006 slaven [...] rezic.de - Correspondence added
Subject: Re: [rt.cpan.org #21407] Build failed due to missing pptemplate
Date: 26 Sep 2006 00:06:08 +0200
To: bug-PDL [...] rt.cpan.org
From: Slaven Rezic <slaven [...] rezic.de>
"Christopher Marshall via RT" <bug-PDL@rt.cpan.org> writes: Show quoted text
> <URL: http://rt.cpan.org/Ticket/Display.html?id=21407 > > > On Mon Sep 25 16:00:56 2006, slaven@rezic.de wrote:
> > > > > > When you modified OPENGL_INC to include the locations for > > > your system (e.g. $Config{locincpth}), did the PDL build > > > complete (w GNU make)? The PDL::Graphics::TriD::OpenGL > > > code is being refactored for the next major release of PDL. > > > We'll try to improve the build process as well at that time.
> > > > It compiles if I set > > > > OPENGL_LIBS => "-L/usr/X11R6/lib", > > OPENGL_INC => "-I/usr/X11R6/include", > > > > in perldl.conf
> > Excellent! I'll be sure that those two directories are added > to the appropriate config search paths. By the way, were > these directories in your $Config{loclibpth} and $Config{locincpth}?
No: $ perl -MConfig -e 'warn $Config{locincpth}; warn $Config{loclibpth}' /usr/local/include /opt/local/include /usr/gnu/include /opt/gnu/include /usr/GNU/include /opt/GNU/include at -e line 1. /usr/local/lib /opt/local/lib /usr/gnu/lib /opt/gnu/lib /usr/GNU/lib /opt/GNU/lib at -e line 1. The "myConfig" script in the Tk distribution has a *very* extensive search for the X11 library and include paths. Show quoted text
>
> > "gmake test" has only the following failures: > > > > t/dumper....................# Failed test 10 in t/dumper.t at line 70 > > # t/dumper.t line 70 is: ok(!$@); > > # Failed test 11 in t/dumper.t at line 84 > > # t/dumper.t line 84 is: ok((ref $a eq 'HASH')); > > # Failed test 12 in t/dumper.t at line 85 > > # t/dumper.t line 85 is: ok((ref $a->{e} eq 'PDL') > > # Failed test 14 in t/dumper.t at line 94 > > # t/dumper.t line 94 is: ok(!$@ && (ref $a eq 'ARRAY')); > > # Failed test 15 in t/dumper.t at line 96 > > # t/dumper.t line 96 is: ok(eval '$a->[0]->hdrcpy() == 1 && $a->[1]-
> > >hdrcpy() == 0');
> > # Failed test 16 in t/dumper.t at line 97 > > # t/dumper.t line 97 is: ok(eval '($a->[0]->gethdr()->{ok}==1) && > > ($a->[1]->gethdr()->{ok}==2)'); > > FAILED tests 10-12, 14-16 > > Failed 6/16 tests, 62.50% okay
> > Could try running the test by hand to see if there are any > additional error messages? Try > > perl -Mblib t/dumper.t > > from the top level PDL-2.4.3 build directory. I took a quick > look at the Dumper.pm code at the failed tests need uuencode > and uudecode to function correctly? Are they available on > your system and in your path? >
The dumper.t output is attached. In fact, the temporary fits files are created, but in the PDL directory, not in /tmp. I think this is because uudecode on FreeBSD just uses the basename of the file for extracting. From the uudecode manpage: -s Do not strip output pathname to base filename. By default uudecode deletes any prefix ending with the last slash '/' for security reasons. Maybe it's best to not trust the filename in the uuencoded file at all. What about: -o output_file Output to output_file instead of any pathname contained in the input data. -p Decode file and write output to standard output. But I don't know how portable this is across operating systems... Regards, Slaven
Download dumper.log
application/octet-stream 12.9k

Message body not shown because it is not plain text.

-- Slaven Rezic - slaven <at> rezic <dot> de babybike - routeplanner for cyclists in Berlin handheld (e.g. Compaq iPAQ with Linux) version of bbbike http://bbbike.sourceforge.net
  Mon Sep 25 19:21:58 2006 chm [...] cpan.org - Correspondence added
On Mon Sep 25 18:06:20 2006, slaven@rezic.de wrote: Show quoted text
> "Chris Marshall via RT" <bug-PDL@rt.cpan.org> writes:
> > > > perl -Mblib t/dumper.t > > > > from the top level PDL-2.4.3 build directory. I took a quick > > look at the Dumper.pm code at the failed tests need uuencode > > and uudecode to function correctly? Are they available on > > your system and in your path? > >
> > The dumper.t output is attached. In fact, the temporary fits files are > created, but in the PDL directory, not in /tmp. > > I think this is because uudecode on FreeBSD just uses the basename of > the file for extracting. From the uudecode manpage: > > -s Do not strip output pathname to base filename. By default > uudecode deletes any prefix ending with the last slash '/' > for > security reasons. > > Maybe it's best to not trust the filename in the uuencoded file at > all. What about: > > -o output_file > Output to output_file instead of any pathname contained in > the > input data. > > -p Decode file and write output to standard output. > > But I don't know how portable this is across operating systems...
I think the portability across OS and uuencode/uudecode versions is indeed the crux of the problem. I think we're getting close. Could you try editing the Dumper.pm in PDL-2.4.3/IO at line 420: 419 ... 420 $uudecode_string .= " -s" if $^O eq "darwin"; 421 ... and replace "darwin" with your OS's value for $^O or add another line just for your OS. Then try the tests again. (You'll need to rebuild or edit the Dumper.pm under the blib/ directory instead). With luck, that should work and is a specific fix we could add to the Dumper.pm source. Regards, Chris
  Tue Sep 26 02:07:34 2006 slaven [...] rezic.de - Correspondence added
CC: SREZIC [...] cpan.org
Subject: Re: [rt.cpan.org #21407] Build failed due to missing pptemplate
Date: 26 Sep 2006 08:07:24 +0200
To: bug-PDL [...] rt.cpan.org
From: Slaven Rezic <slaven [...] rezic.de>
"Christopher Marshall via RT" <bug-PDL@rt.cpan.org> writes: Show quoted text
> <URL: http://rt.cpan.org/Ticket/Display.html?id=21407 > > > On Mon Sep 25 18:06:20 2006, slaven@rezic.de wrote:
> > "Chris Marshall via RT" <bug-PDL@rt.cpan.org> writes:
> > > > > > perl -Mblib t/dumper.t > > > > > > from the top level PDL-2.4.3 build directory. I took a quick > > > look at the Dumper.pm code at the failed tests need uuencode > > > and uudecode to function correctly? Are they available on > > > your system and in your path? > > >
> > > > The dumper.t output is attached. In fact, the temporary fits files are > > created, but in the PDL directory, not in /tmp. > > > > I think this is because uudecode on FreeBSD just uses the basename of > > the file for extracting. From the uudecode manpage: > > > > -s Do not strip output pathname to base filename. By default > > uudecode deletes any prefix ending with the last slash '/' > > for > > security reasons. > > > > Maybe it's best to not trust the filename in the uuencoded file at > > all. What about: > > > > -o output_file > > Output to output_file instead of any pathname contained in > > the > > input data. > > > > -p Decode file and write output to standard output. > > > > But I don't know how portable this is across operating systems...
> > I think the portability across OS and uuencode/uudecode versions > is indeed the crux of the problem. I think we're getting close. > > Could you try editing the Dumper.pm in PDL-2.4.3/IO at line 420: > > 419 ... > 420 $uudecode_string .= " -s" if $^O eq "darwin"; > 421 ... > > and replace "darwin" with your OS's value for $^O or > add another line just for your OS. Then try the tests > again. (You'll need to rebuild or edit the Dumper.pm > under the blib/ directory instead). With luck, that should > work and is a specific fix we could add to the Dumper.pm > source.
All tests pass if I change the line to: $uudecode_string .= " -s" if $^O =~ m{^(darwin|freebsd|netbsd|openbsd)$}; My os string is "freebsd", but I bet that all other BSDs need the same fix. Regards, Slaven -- Slaven Rezic - slaven <at> rezic <dot> de Tk-AppMaster: a perl/Tk module launcher designed for handhelds http://tk-appmaster.sf.net
  Tue Sep 26 21:33:55 2006 chm [...] cpan.org - Correspondence added
On Tue Sep 26 02:07:34 2006, slaven@rezic.de wrote: Show quoted text
> "Chris Marshall via RT" <bug-PDL@rt.cpan.org> writes:
> > > > Could you try editing the Dumper.pm in PDL-2.4.3/IO at line 420: > > > > 419 ... > > 420 $uudecode_string .= " -s" if $^O eq "darwin"; > > 421 ... > > > > and replace "darwin" with your OS's value for $^O or > > add another line just for your OS. Then try the tests > > again. (You'll need to rebuild or edit the Dumper.pm > > under the blib/ directory instead). With luck, that should > > work and is a specific fix we could add to the Dumper.pm > > source.
> > All tests pass if I change the line to: > > $uudecode_string .= " -s" if $^O =~ m{^(darwin|freebsd|netbsd|openbsd)$}; > > My os string is "freebsd", but I bet that all other > BSDs need the same fix.
Slaven, Thanks for helping to resolve this issue. The bug status to date: 1. The original problem with a failed pmake appears to result from MakeMaker generating Makefiles with a circular graph under some circumstances. The current fix does not work for the PDL build. The next step is to report the problem as a MakeMaker bug for further work. The current work around is to use GNU make rather than pmake to build. 2. The include files and library paths for TriD(OpenGL) is not correct for FreeBSD. Hand editing perldl.conf with OPENGL_LIBS => "-L/usr/X11R6/lib", OPENGL_INC => "-I/usr/X11R6/include", fixed the build problem here. We need to patch the current code to check these paths for FreeBSD (and possibly other OSes). 3. Finally, there was a problem with PDL/IO/Dumper.pm where the BSD uudecode command needs the -s option to preserve full pathnames for the decoded files. After editing the Dumper.pm file to add the -s flag option for *bsd OSes, the dumper.t tests pass. I hope that you have a working PDL at this time. I'll put up patches against PDL-2.4.3 on the sourceforge.net site for items #2 and #3. For item #1, I'll see about how to best report the on-going problem to the ExtUtils::MakeMaker developers. With that, I hope this resolves the bug for you. If so, we can update the status of this problem ticket once the patches are up on sourceforge (I expect to get to that this weekend). Thanks again for your feedback and help in solving these problems. Happy PDL-ing. Regards, Chris expect to get the patches in by this weekend. --Chris
  Sun Oct 08 12:24:24 2006 chm [...] cpan.org - Correspondence added
From: chm [...] alum.mit.edu
On Tue Sep 26 21:33:55 2006, CHM wrote: Show quoted text
> ... > > 1. The original problem with a failed pmake appears to result > from MakeMaker generating Makefiles with a circular graph > under some circumstances. The current fix does not work for > the PDL build. The next step is to report the problem as a > MakeMaker bug for further work. The current work around > is to use GNU make rather than pmake to build.
Use GNU make. With the cpan shell, you can change the make command being used with the command: Show quoted text
cpan> o conf make '/my/path/to/gnumake'
before doing the install PDL build. If you are doing the initial CPAN configuration, just select GNUmake when you are prompted for your make command. Show quoted text
> > 2. The include files and library paths for TriD(OpenGL) > is not correct for FreeBSD. Hand editing perldl.conf > with > > OPENGL_LIBS => "-L/usr/X11R6/lib", > OPENGL_INC => "-I/usr/X11R6/include", > > fixed the build problem here. We need to patch the > current code to check these paths for FreeBSD (and > possibly other OSes).
Please try the attached patch against a clean PDL-2.4.3 and let me know if it works for you. Show quoted text
> 3. Finally, there was a problem with PDL/IO/Dumper.pm where > the BSD uudecode command needs the -s option to preserve > full pathnames for the decoded files. After editing the > Dumper.pm file to add the -s flag option for *bsd OSes, > the dumper.t tests pass.
Again, please confirm that the attached patch file fixes the problem. Show quoted text
> I hope that you have a working PDL at this time. I'll > put up patches against PDL-2.4.3 on the sourceforge.net > site for items #2 and #3. > > For item #1, I'll see about how to best report the on-going > problem to the ExtUtils::MakeMaker developers. > > With that, I hope this resolves the bug for you. If so, we > can update the status of this problem ticket once the > patches are up on sourceforge (I expect to get to that this > weekend). Thanks again for your feedback and help in > solving these problems.
For more timely feedback, please refer to the PDL project pages on sourceforge. I have entered the OPENGL_INC and Dumper.pm problems as bugs #1573215 and #1573217. For example the attached patch may also be found as patch #1573228 at https://sourceforge.net/tracker/?group_id=612&atid=300612 I look forward to hearing from you whether this patch resolves your problems. Thanks, Chris
diff -Naur PDL-2.4.3/Graphics/Makefile.PL PDL-2.4.3-freebsd-fix/Graphics/Makefile.PL --- PDL-2.4.3/Graphics/Makefile.PL 2006-08-16 22:46:37.000000000 -0400 +++ PDL-2.4.3-freebsd-fix/Graphics/Makefile.PL 2006-10-08 11:23:08.734375000 -0400 @@ -62,6 +62,13 @@ '-DGLX_NV_vertex_array_range'; } + # hack for FreeBSD + # chm: Need to add include path check that #include <GL/gl.h> works + # + if ($^O eq "freebsd" and not defined $PDL::Config{OPENGL_INC}) { + $PDL::Config{OPENGL_INC} = "-I/usr/X11R6/include"; + } + # hack for OS-X if ($^O eq "darwin" and not defined $PDL::Config{OPENGL_INC}) { $PDL::Config{OPENGL_INC} = "-I/usr/X11R6/include"; diff -Naur PDL-2.4.3/IO/Dumper.pm PDL-2.4.3-freebsd-fix/IO/Dumper.pm --- PDL-2.4.3/IO/Dumper.pm 2006-03-14 18:19:11.000000000 -0500 +++ PDL-2.4.3-freebsd-fix/IO/Dumper.pm 2006-10-08 11:18:49.890625000 -0400 @@ -417,7 +417,7 @@ # so we go this way for now as it is less-likely to break things # my $uudecode_string = "|uudecode"; -$uudecode_string .= " -s" if $^O eq "darwin"; +$uudecode_string .= " -s" if $^O eq "darwin" or $^O eq "freebsd" or $^O eq "openbsd"; sub PDL::IO::Dumper::uudecode_PDL { my $lines = shift;
  Sun Oct 08 12:27:30 2006 chm [...] cpan.org - Correspondence added
If the following cpan command did not show up, please use the attached message body. Show quoted text
> > Use GNU make. With the cpan shell, you can change the make > command being used with the command: >
> cpan> o conf make '/my/path/to/gnumake'
> > before doing the install PDL build. If you are doing the > initial CPAN configuration, just select GNUmake when you > are prompted for your make command.
Don't know what happened there. --Chris
  Sat Oct 14 16:57:41 2006 SREZIC [...] cpan.org - Correspondence added
From: SREZIC [...] cpan.org
On Sun Oct 08 12:24:24 2006, CHM wrote: [...] Show quoted text
> I look forward to hearing from you whether this patch resolves > your problems.
"All tests successful" with the patch and when using gmake instead of make. I would also like to inform you that the brand new developer version of CPAN.pm 1.88_54 gives the user the ability to define "distribution preferences". The attached yaml file is such a distribution prefs file, which would use "gmake" instead of "make" in the CPAN building process, but only for PDL. Regards, Slaven
--- match: module: "^PDL$" cpanconfig: make: "/usr/local/bin/gmake" make_install_make_command: "sudo gmake"
  Sun Jun 15 18:06:01 2008 chm [...] cpan.org - Correspondence added
See http://sourceforge.net/tracker/?func=browse&group_id=612&atid=100612 bug # 1994598 for follow up and resolution.
  Mon Oct 20 16:32:51 2008 chm [...] cpan.org - Fixed in 2.4.3_01 added
  Mon Oct 20 16:32:56 2008 chm [...] cpan.org - Correspondence added
The PDL-2.4.3_01 release (a prerelease for an official PDL-2.4.4 one) has this fix in it. Please follow up on the PDL sourceforge.net bug tracker with any additional issues. Thanks for reporting the problem.
  Mon Oct 20 16:33:29 2008 chm [...] cpan.org - Status changed from 'open' to 'resolved'
  Wed Apr 27 10:54:24 2011 chm [...] cpan.org - Fixed in 2.4.4 added
  Wed Apr 27 10:54:24 2011 chm [...] cpan.org - Fixed in 2.4.3_01 deleted