Proc::ProcessTable needs a C lover
I just tried to install Server::Control on a linux box.
It depends on Proc::ProcessTable which blew up during testing:
t/process.t .. Can't load '/home/gabor/.cpan/build/ Proc-ProcessTable-0.45-rKuJSH/blib/arch/auto/ Proc/ProcessTable/ProcessTable.so' for module Proc::ProcessTable: /home/gabor/.cpan/build/ Proc-ProcessTable-0.45-rKuJSH/blib/arch/auto/ Proc/ProcessTable/ProcessTable.so: undefined symbol: pthread_once at /opt/dwimperl-5.16.0.1/perl/lib/5.16.0/x86_64-linux/ DynaLoader.pm line 190. at t/process.t line 9.(I had to break the lines of the error as putting it in <pre> tags caused the lines to be cut off. Sorry for that.)
I have not yet figured out if I could just force install and get awy with it or not, but I looked at the state of that module. 40% test repors failed and it has 49 open bugs.
On the other direction 23 other modules depend on this one.
I don't have the knowledge, nor the tuits for this module, but if you have some time and some C knowledge, this could be a nice module to fix.
I blog about Perl.
First look for existing fixes, such as in the RT queue.
Many maintainers stay unresponsive,
so CPAN came up with the distoprefs.
My patch for this problem is is at https://github.com/rurban/distroprefs/tree/master/sources/authors/id/R/RU/RURBAN/patches
There much more than just this module.
Proc::ProcessTable 0.45 is terribly broken on Perls with threading turned off.
Install Proc::ProcessTable 0.44 and things should work fine.
I would love to know how to remove Proc::ProcessTable 0.45 from CPAN, or re-release 0.44 as 0.46. The author has pretty much vanished.
Hi
This is scary. I'm using Server::Control V 0.20 and Proc::ProcessTable V 0.45 under Debian 6/64 bit (stable) without problems.
I normally use cpanm but now I just downloaded Server::Control and ran the tests without problems.
Is it more of an OS issue?
Cheers
Ron
@Ron, as I understand from the post of @Jonathan, this is a problem with the non-threaded Perl I have. (Which is actually DWIM Perl for linux)
@Jonathan, @Reini, thanks for your answers.
I hope someone will took over maintenance of this module and fix the issues. Maybe someone will ask for a TPF grant for this work.
Hi Gabor
Understood. Sorry for the terse q.
I was fishing for info as to whether or not transferring the code to a similar-but-different OS would incur these problems.
The Linux patch I apply is https://rt.cpan.org/Public/Bug/Display.html?id=41397 -- there are others, but I seem to get along without them.
Under OpenBSD, I apply https://rt.cpan.org/Public/Bug/Display.html?id=77094
Perhaps more interestingly, a respondent to that ticket expressed the intent to refactor the module. And publish? Who knows?