SGI: Development

Perl CPAN failing to install modules

I think Josehill is indeed right:

Before entering nekoware perl CPAN shell, try to do this first:

Code: Select all

chkconfig vswap on

This seems to work on my ChallengeS, at least installing a new CPAN. Khalid, can you test this?

[edit] before this, i added extra swap via a swap file, but that didn't help, Maybe the combination of vswap and adding extra swap did the trick. In order to test vswap without extra swap, i have to let CPAN go its course, which takes a rather long time. :(
:Crimson: :PI: :Indigo: :O2: :Indy: :Indigo2: :Indigo2IMP:
Mine fails saying can't fork is that a symptom of out of memory? My o2 has the same issue with 1gb ram
############################
Re-install with OpenBSD :)
Um, how big is your swap? I now have:

Code: Select all

cyane:/home/frank> swap -l
lswap path         dev    pri swaplo   blocks     free  maxswap    vswap
2 /swap/swap1
0,46     2      0   262144   262144   262144        0
1 /dev/swap
0,50     0      0   262144   251000   262144        0

My Challenge S only has 192MB ram

[EDIT] i have vswap off to test if an 'install CPAN' fails. Takes a while... Result is inconclusive, but i happen to forget to enable vswap after the chkconfig. The correct command sequence should be:

Code: Select all

chkconfig vswap on
/etc/init.d/swap start

I now have

Code: Select all

cyane:/etc# swap -l
lswap path         dev    pri swaplo   blocks     free  maxswap    vswap
2 /swap/swap1
0,46     2      0   262144   262144   262144        0
3 /.swap.virtual
0,46     2      0        0        0        0    80000
1 /dev/swap
0,50     0      0   262144   246352   262144        0

More later...
:Crimson: :PI: :Indigo: :O2: :Indy: :Indigo2: :Indigo2IMP:
If this is the scenario I'm thinking of, the man page for swap explains why turning on virtual swap (vswap) can work, even when adding additional swap files or actual physical memory does not help:

If the amount of private virtual space requested exceeds the available logical swap space, the system call fails with EAGAIN and an "out of logical swap space" message is logged on the console. The system does this in order to prevent memory deadlocks from occurring...

...Programs that have large address spaces and large programs that fork, may receive EAGAIN along with the "out of logical swap space" message on the console. This can also happen when debugging a large program with dbx or other debugger. There are two ways to avoid this error: adding more real swap space, or adding virtual swap space...

...(Virtual swap) increases the amount of logical swap space without using any physical disk space. This is suitable when the programs involved do not intend to use the virtual address space they allocate (i.e., when the address space is sparse or when a large program that forks intends to exec soon afterwards without modifying many pages). In these cases, physical swap space is not required and so adding virtual swap space allows the kernel to complete the logical swap space reservation and avoid the EAGAIN errors. The advantage of this approach is that it does not require any disk space, but adds the risk of encountering a memory deadlock.
I would never have guessed it needed more swap space... I really don't get why. The process didn't seem to run out of memory. The can't fork issue was so cryptic.

Anyway install CPAN worked. My SSL module won't build probably because SSL is broken on the box.

Thanks for the solution! Much appreciated
############################

Re-install with OpenBSD :)
khalidschofield wrote: Anyway install CPAN worked. My SSL module won't build probably because SSL is broken on the box.

I've revisited this problem today since we have proper openssl alternatives now:
Brent Canavan and i have made new packages for neko_openssl and i could successfully build Net-SSLeay-1.81 aka Net::SSLeay as a prerequisite for IO::Socket::SSL

CPAN module is really backwards when it comes to building modules from C libraries installed on the system, because the inclusion of nonstandard header and library location is apparently not standardized in itself and depends on how people have coded it inside Makefile.PL
I also have the feeling that the CPAN module and its shell does not incorporate environments from the parent tcsh or ksh. I tried all sorts of things like CPATH, CFLAGS, --incpath, -I, INC="-I<path" and whatnot.

So i pulled the sources and compiled it manually via this recipe:

Code: Select all

> wget http://search.cpan.org/CPAN/authors/id/M/MI/MIKEM/Net-SSLeay-1.81.tar.gz
> gunzip -c Net-SSLeay-1.81.tar.gz | tar xvf -
> cd Net-SSLeay-1.81
> /usr/nekoware/bin/perl Makefile.PL INC="-I/usr/nekoware/include"
> gmake

With "gmake install" as root it should put the module into the site specific portion of nekoware perl

I'm not sure if you still need this, but i think it's good for some folks who have this problem in the future.

Now, back to Python! :)
:Crimson: :PI: :Indigo: :O2: :Indy: :Indigo2: :Indigo2IMP: