Skip Menu |
 

This queue is for tickets about the Math-GSL CPAN distribution.

Report information
The Basics
Id: 50960
Status: resolved
Priority: 0/
Queue: Math-GSL

People
Owner: Nobody in particular
Requestors: parekh.deven [...] gmail.com
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: (no value)



Subject: ./Build test fails
Date: Fri, 30 Oct 2009 00:17:15 -0500
To: bug-Math-Gsl [...] rt.cpan.org
From: Deven Parekh <parekh.deven [...] gmail.com>
Download (untitled) / with headers
text/plain 2.9k
I tried to install Math::GSL First had problems with ./Build since it could not find CORE headers. Got around it by doing perl Makefile.PL INC="-I /usr/lib/perl5/5.10.0/i386-linux-thread-multi/CORE" After that the build was successful but the test fails Test Summary Report ------------------- t/CBLAS.t (Wstat: 6 Tests: 4 Failed: 0) Non-zero wait status: 6 Parse errors: Bad plan. You planned 5 tests but ran 4. t/QRNG.t (Wstat: 6 Tests: 2 Failed: 0) Non-zero wait status: 6 Parse errors: Bad plan. You planned 8 tests but ran 2. t/Sort.t (Wstat: 6 Tests: 2 Failed: 0) Non-zero wait status: 6 Parse errors: Bad plan. You planned 20 tests but ran 2. Files=52, Tests=3612, 15 wallclock secs ( 0.87 usr 0.14 sys + 13.34 cusr 0.84 csys = 15.19 CPU) Result: FAIL Failed 3/52 test programs. 0/3612 subtests failed. Each of the test for t/CBLAS.t t/QRNG.t and t/Sort.t is failing with stack trace output with following messages respectively t/CBLAS.t .......... 1/5 *** glibc detected *** /usr/bin/perl: munmap_chunk(): invalid pointer: 0xbfc24908 *** ======= Backtrace: ========= /lib/libc.so.6[0x55f2a1] /lib/libc.so.6[0x5604c5] /home/auto/Download/Math-GSL-0.20/blib/arch/auto/Math/GSL/CBLAS/CBLAS.so(_wrap_cblas_sgemm+0x1ea7)[0x917879] /usr/lib/perl5/5.10.0/i386-linux-thread-multi/CORE/libperl.so(Perl_pp_entersub+0x8ca)[0x31160a] /usr/lib/perl5/5.10.0/i386-linux-thread-multi/CORE/libperl.so(Perl_runops_debug+0x154)[0x2d50f4] /usr/lib/perl5/5.10.0/i386-linux-thread-multi/CORE/libperl.so(perl_run+0x5c7)[0x309c87] /usr/bin/perl(main+0x106)[0x8048a26] /lib/libc.so.6(__libc_start_main+0xe6)[0x505a66] t/QRNG.t ........... 1/8 *** glibc detected *** /usr/bin/perl: double free or corruption (out): 0xbfe3f890 *** ======= Backtrace: ========= /lib/libc.so.6[0x2af2a1] /home/auto/Download/Math-GSL-0.20/blib/arch/auto/Math/GSL/QRNG/QRNG.so(_wrap_gsl_qrng_get+0x544)[0x9bcb78] /usr/lib/perl5/5.10.0/i386-linux-thread-multi/CORE/libperl.so(Perl_pp_entersub+0x8ca)[0x72260a] /usr/lib/perl5/5.10.0/i386-linux-thread-multi/CORE/libperl.so(Perl_runops_debug+0x154)[0x6e60f4] /usr/lib/perl5/5.10.0/i386-linux-thread-multi/CORE/libperl.so(perl_run+0x5c7)[0x71ac87] /usr/bin/perl(main+0x106)[0x8048a26] /lib/libc.so.6(__libc_start_main+0xe6)[0x255a66] /usr/bin/perl[0x8048881] t/Sort.t ........... 1/20 *** glibc detected *** /usr/bin/perl: free(): invalid next size (fast): 0x086bd7d8 *** ======= Backtrace: ========= /lib/libc.so.6[0x2af2a1] /home/auto/Download/Math-GSL-0.20/blib/arch/auto/Math/GSL/Sort/Sort.so(_wrap_gsl_sort_index+0x1052)[0x7aaef1] /usr/lib/perl5/5.10.0/i386-linux-thread-multi/CORE/libperl.so(Perl_pp_entersub+0x8ca)[0xd5f60a] /usr/lib/perl5/5.10.0/i386-linux-thread-multi/CORE/libperl.so(Perl_runops_debug+0x154)[0xd230f4] /usr/lib/perl5/5.10.0/i386-linux-thread-multi/CORE/libperl.so(perl_run+0x5c7)[0xd57c87] /usr/bin/perl(main+0x106)[0x8048a26] /lib/libc.so.6(__libc_start_main+0xe6)[0x255a66] /usr/bin/perl[0x8048881]
Download (untitled) / with headers
text/plain 3.3k
When trying to run 'make' for Math::GSL 0.20 I also run into this problem: several basic header files for perl were not found by the preprocessor. After some time with the Perl debugger I managed to track down the root cause for this very bizarre error message: At line 207 in the file Math-GSL-0.20/Build.PL, change include_dirs => q{}, into include_dirs => [], The intent with both lines (the faulty as well as the corrected version) is to tell Build.PL that "there are no additional include dirs". Unfortunately will the incorrect line be interpreted by the build infrastructure as "Please add to the list of include directories a path consisting of the empy string". The build infrastructure happily obeys this request and causes a single '-I' to be added to the gcc calls used to compile various C code. The bad thing with that single '-I' is that gcc does not interpret as "please add a path consisting of the empty string to the list of include directories", instead it is interpreted as "please add the NEXT command line, in it's ENTIRETY, to the list of directories to search for include files". The reason for THAT to be a bad thing is that the next command line does not end up be anything that starts with something like "/usr/lib/perl...", but instead it starts with "-I/usr/lib/perl..." and THAT is not a valid directory at all. Yes, what happens is that gcc, by that single '-I' flags being added to the beginning of all command line arguments, gets confused and fails to recognize the following '-I' flag which is used to add the directory with the core perl header files to the path of directories to searh for header files. Thus the nasty surprise with a build that fails to find the very basic, fundamental perl header files. Sorry for the long description above, but I thought that once I managed to track down that chain of events, I better document it. Actually, it seems like a similar spurious lone '-I' has confused builds of other perl modules at some occasions. How to solve this? Well, the straighforward "keep it simple stupid" approach is to do like I suggest above and just correct the 'include_dirs' parameter to specify an empty list instead of an empty string. A more bullet proof way to do it is to change the build infrastructure somehow to make it actually fail and complain with a very clear and informative error message whenever the empty string is specified as the value for 'include_dirs'. This will help developers/maintainers to avoid that pitfall and instead specify the properly working empty list as the "no additional include directories" value. A less ideal way to solve it is to make the build infrastructure silently replace any empty string specified for 'include_dirs' with an empty list. However, I'm a believer in enforcing a certain level of strictness and correctness, and would prefer to not forgive an imprecise and easily misunderstood value being specified as the 'include_dirs' (but that's just my personal preference). Of course, I don't know how easily it is to add the above two suggested fixes (the explicit, informative error message as well as the "behind the scenes" correction of the problematic value) to the build infrastructure. Perhaps it is just a change in some code already in this package (then it is easy) but it might also require change in some change in Module::Build etc. Ok, enough said. I hope this reply is considered helpful.
Subject: Re: [rt.cpan.org #50960] ./Build test fails
Date: Mon, 30 Nov 2009 09:58:34 -0800
To: bug-Math-Gsl [...] rt.cpan.org
From: Jonathan Leto <jonathan [...] leto.net>
Download (untitled) / with headers
text/plain 4.4k
Howdy, Thanks so much for figuring this out! I will make that change as soon as possible. I really appreciate the time you took to figure it out and then all the time you took to properly explain it. You rock! Is there a way to test this in the Math::GSL test suite? Do you have the output of what the error output looks like? I know I have seen what you are talking about, but I want to verify what you are seeing is the same. Would you like a commit bit to the Math::GSL github repo? You could then make topic branches for your patches and I could merge them into master easily. If you are not familiar with git, I can help with that. Duke On Mon, Nov 30, 2009 at 7:59 AM, Jakob Ilves via RT <bug-Math-Gsl@rt.cpan.org> wrote: Show quoted text
>       Queue: Math-Gsl >  Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=50960 > > > When trying to run 'make' for Math::GSL 0.20 I also run into this > problem: several basic header files for perl were not found by the > preprocessor.  After some time with the Perl debugger I managed to track > down the root cause for this very bizarre error message: > > At line 207 in the file Math-GSL-0.20/Build.PL, change > >    include_dirs            => q{}, > > into > >    include_dirs            => [], > > > The intent with both lines (the faulty as well as the corrected version) > is to tell Build.PL that "there are no additional include dirs". > Unfortunately will the incorrect line be interpreted by the build > infrastructure as "Please add to the list of include directories a path > consisting of the empy string".  The build infrastructure happily obeys > this request and causes a single '-I' to be added to the gcc calls used > to compile various C code.  The bad thing with that single '-I' is that > gcc does not interpret as "please add a path consisting of the empty > string to the list of include directories", instead it is interpreted as > "please add the NEXT command line, in it's ENTIRETY, to the list of > directories to search for include files".  The reason for THAT to be a > bad thing is that the next command line does not end up be anything that > starts with something like "/usr/lib/perl...", but instead it starts > with "-I/usr/lib/perl..." and THAT is not a valid directory at all. > Yes, what happens is that gcc, by that single '-I' flags being added to > the beginning of all command line arguments, gets confused and fails to > recognize the following '-I' flag which is used to add the directory > with the core perl header files to the path of directories to searh for > header files.  Thus the nasty surprise with a build that fails to find > the very basic, fundamental perl header files. > > Sorry for the long description above, but I thought that once I managed > to track down that chain of events, I better document it.  Actually, it > seems like a similar spurious lone '-I' has confused builds of other > perl modules at some occasions. > > How to solve this?  Well, the straighforward "keep it simple stupid" > approach is to do like I suggest above and just correct the > 'include_dirs' parameter to specify an empty list instead of an empty > string. > > A more bullet proof way to do it is to change the build infrastructure > somehow to make it actually fail and complain with a very clear and > informative error message whenever the empty string is specified as the > value for 'include_dirs'.  This will help developers/maintainers to > avoid that pitfall and instead specify the properly working empty list > as the "no additional include directories" value. > > A less ideal way to solve it is to make the build infrastructure > silently replace any empty string specified for 'include_dirs' with an > empty list.  However, I'm a believer in enforcing a certain level of > strictness and correctness, and would prefer to not forgive an imprecise > and easily misunderstood value being specified as the 'include_dirs' > (but that's just my personal preference). > > Of course, I don't know how easily it is to add the above two suggested > fixes (the explicit, informative error message as well as the "behind > the scenes" correction of the problematic value) to the build > infrastructure.  Perhaps it is just a change in some code already in > this package (then it is easy) but it might also require change in some > change in Module::Build etc. > > Ok, enough said.  I hope this reply is considered helpful. > >
-- Jonathan "Duke" Leto jonathan@leto.net http://leto.net
Subject: Re: [rt.cpan.org #50960] ./Build test fails
Date: Mon, 8 Feb 2010 21:36:02 -0600
To: bug-Math-Gsl [...] rt.cpan.org
From: Deven Parekh <parekh.deven [...] gmail.com>
Download (untitled) / with headers
text/plain 3.7k
Thank you folks. You guys are GOOD! Appreciate your time and effort with this. I will try the empty include_dirs workaround. Best Regards Deven. On Mon, Nov 30, 2009 at 9:59 AM, Jakob Ilves via RT < bug-Math-Gsl@rt.cpan.org> wrote: Show quoted text
> <URL: https://rt.cpan.org/Ticket/Display.html?id=50960 > > > When trying to run 'make' for Math::GSL 0.20 I also run into this > problem: several basic header files for perl were not found by the > preprocessor. After some time with the Perl debugger I managed to track > down the root cause for this very bizarre error message: > > At line 207 in the file Math-GSL-0.20/Build.PL, change > > include_dirs => q{}, > > into > > include_dirs => [], > > > The intent with both lines (the faulty as well as the corrected version) > is to tell Build.PL that "there are no additional include dirs". > Unfortunately will the incorrect line be interpreted by the build > infrastructure as "Please add to the list of include directories a path > consisting of the empy string". The build infrastructure happily obeys > this request and causes a single '-I' to be added to the gcc calls used > to compile various C code. The bad thing with that single '-I' is that > gcc does not interpret as "please add a path consisting of the empty > string to the list of include directories", instead it is interpreted as > "please add the NEXT command line, in it's ENTIRETY, to the list of > directories to search for include files". The reason for THAT to be a > bad thing is that the next command line does not end up be anything that > starts with something like "/usr/lib/perl...", but instead it starts > with "-I/usr/lib/perl..." and THAT is not a valid directory at all. > Yes, what happens is that gcc, by that single '-I' flags being added to > the beginning of all command line arguments, gets confused and fails to > recognize the following '-I' flag which is used to add the directory > with the core perl header files to the path of directories to searh for > header files. Thus the nasty surprise with a build that fails to find > the very basic, fundamental perl header files. > > Sorry for the long description above, but I thought that once I managed > to track down that chain of events, I better document it. Actually, it > seems like a similar spurious lone '-I' has confused builds of other > perl modules at some occasions. > > How to solve this? Well, the straighforward "keep it simple stupid" > approach is to do like I suggest above and just correct the > 'include_dirs' parameter to specify an empty list instead of an empty > string. > > A more bullet proof way to do it is to change the build infrastructure > somehow to make it actually fail and complain with a very clear and > informative error message whenever the empty string is specified as the > value for 'include_dirs'. This will help developers/maintainers to > avoid that pitfall and instead specify the properly working empty list > as the "no additional include directories" value. > > A less ideal way to solve it is to make the build infrastructure > silently replace any empty string specified for 'include_dirs' with an > empty list. However, I'm a believer in enforcing a certain level of > strictness and correctness, and would prefer to not forgive an imprecise > and easily misunderstood value being specified as the 'include_dirs' > (but that's just my personal preference). > > Of course, I don't know how easily it is to add the above two suggested > fixes (the explicit, informative error message as well as the "behind > the scenes" correction of the problematic value) to the build > infrastructure. Perhaps it is just a change in some code already in > this package (then it is easy) but it might also require change in some > change in Module::Build etc. > > Ok, enough said. I hope this reply is considered helpful. > >
Download (untitled) / with headers
text/plain 130b
the include_dirs bug was fixed and the double free's should be fixed as well. If other problems persist, please submit a new bug.


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.