Open GoogleCodeExporter opened 9 years ago
Same problem here:
MSSII2:~ # ipkg install slimrat
Installing slimrat (1.0-1) to root...
Downloading http://ipkg.nslu2-
linux.org/feeds/optware/cs05q3armel/cross/stable/slimrat_1.0-1_arm.ipk
Installing perl-libwww (5.825-1) to root...
Downloading
http://ipkg.nslu2-linux.org/feeds/optware/cs05q3armel/cross/stable/perl-
libwww_5.825-1_arm.ipk
Installing perl (5.8.8-23) to root...
Downloading http://ipkg.nslu2-
linux.org/feeds/optware/cs05q3armel/cross/stable/perl_5.8.8-23_arm.ipk
Installing perl-uri (1.35-3) to root...
Downloading
http://ipkg.nslu2-linux.org/feeds/optware/cs05q3armel/cross/stable/perl-
uri_1.35-3_arm.ipk
Installing perl-compress-zlib (1.42-3) to root...
Downloading
http://ipkg.nslu2-linux.org/feeds/optware/cs05q3armel/cross/stable/perl-
compress-zlib_1.42-3_arm.ipk
Installing perl-html-parser (3.60-1) to root...
Downloading
http://ipkg.nslu2-linux.org/feeds/optware/cs05q3armel/cross/stable/perl-
html-parser_3.60-1_arm.ipk
Installing perl-html-tagset (3.04-4) to root...
Downloading
http://ipkg.nslu2-linux.org/feeds/optware/cs05q3armel/cross/stable/perl-
html-tagset_3.04-4_arm.ipk
Installing perl-www-mechanize (1.54-2) to root...
Downloading
http://ipkg.nslu2-linux.org/feeds/optware/cs05q3armel/cross/stable/perl-
www-mechanize_1.54-2_arm.ipk
Installing perl-http-response-encoding (0.05-1) to root...
Downloading
http://ipkg.nslu2-linux.org/feeds/optware/cs05q3armel/cross/stable/perl-
http-response-encoding_0.05-1_arm.ipk
Configuring perl
Configuring perl-compress-zlib
Configuring perl-html-parser
Configuring perl-html-tagset
Configuring perl-http-response-encoding
Configuring perl-libwww
Configuring perl-uri
Configuring perl-www-mechanize
Configuring slimrat
Successfully terminated.
MSSII2:~ # slimrat
/opt/bin/slimrat line 47:
This Perl hasn't been configured and built properly for the threads
module to work. (The 'useithreads' configuration option hasn't been used.)
Having threads support requires all of Perl and all of the XS modules in
the Perl installation to be rebuilt, it is not just a question of adding
the threads module. (In other words, threaded and non-threaded Perls
are binary incompatible.)
If you want to the use the threads module, please contact the people
who built your Perl.
Cannot continue, aborting.
BEGIN failed--compilation aborted at /opt/lib/perl5/5.8.8/arm-linux/threads.pm
line
28.
Compilation failed in require at /opt/bin/slimrat line 47.
BEGIN failed--compilation aborted at /opt/bin/slimrat line 47.
MSSII2:~ #
Original comment by mcsu...@googlemail.com
on 1 Jan 2010 at 1:24
[deleted comment]
I noticed that ithreads support has been removed from optware's perl because it
broke
many packages. Maybe you can compile a version supporting ithreads yourselves
using
the diffs in http://trac.nslu2-linux.org/optware/changeset/10881. I guess the
other
option would be for the slimrat developers to provide a pthreads version.
Original comment by pim.bo...@gmail.com
on 18 Jan 2010 at 10:39
Hmm. When I wrote the concurrent-download code, interpreter threads seemed the
best
and most portable solution. Also, is there an alternative? I can't find anything
concerning pthreads on perl. Multi-process architecture is currently impossible
(maybe after the proposed rewrite, if I find some time), and could also increase
system load quite a bit.
It's a shame they disabled ithreads, they might have been unstable in previous
versions of perl but tend to work quite well using perl >=5.10.
Original comment by tim.besard@gmail.com
on 18 Jan 2010 at 1:51
Things are even worse in Optware...
I did a 'perl -V' and found out the is no support for threading at all:
usethreads=undef use5005threads=undef useithreads=undef usemultiplicity=undef
I think I will try to contact the person who packaged slimrat (bzhou) because
he/she
also packaged perl.
Original comment by pim.bo...@gmail.com
on 19 Jan 2010 at 9:20
[deleted comment]
Yeah, thanks.
Why are people still using 5.8 anyway, is 5.10 that bad? Only other reason I
could
think of is backwards compatibility with in-house software or libraries, but
that
doesn't apply to regular users, does it... Damn you, (MAC|Gentoo|Optware) users
^^
DEL-EDIT: typo
Original comment by tim.besard@gmail.com
on 19 Jan 2010 at 1:12
It seems that fork() is a viable option after all, as it uses advanced
copy-on-write
paging, minimizing the duplication overhead. It'll require quite a rewrite
though, so
it'll take some months to get implemented (I'm having exams now, hence the
inactivity
lately).
As a temporary workaround, you could try the drop-in forks.pm replacement:
http://search.cpan.org/~rybskej/forks/lib/forks.pm . It'll require you to
change the
"use threads" to "use forks", and alter the thread compatibility clauses (look
for
$THREADCOMP or alike) to match what forks.pm provides.
Original comment by tim.besard@gmail.com
on 19 Jan 2010 at 4:33
Original comment by tim.besard@gmail.com
on 2 Feb 2010 at 11:33
Same here ;(
Original comment by pos...@gmail.com
on 27 Mar 2010 at 11:36
I've been busy lately working on my undergrad project, but should have some
time free
soon.As the Ohloh page reveals though, I've already written a decent part of
code
back in January (laying some foundations).
Original comment by tim.besard@gmail.com
on 28 Mar 2010 at 8:26
Using AnyEvent is a more portable solution and uses less resources than
multiple forks.
Original comment by colossus...@gmail.com
on 29 May 2011 at 5:37
Original issue reported on code.google.com by
martyla...@gmail.com
on 4 Dec 2009 at 12:40