On 3/14/06, Jerry K <[EMAIL PROTECTED]> wrote: > Hello, > > I asked this question, and other than one response (thanks Owen!), > things have been pretty silent on this issue. > > As I am a recent subscriber, maybe this is not the place to post this > type of a request. > > Is there a better place that someone might aim me to resolve this issue? > > Thanks for any replies, > > Jerry K > > > Jerry K wrote: > Jerry,
As others have said: comp.lang.perl.misc. The lack of replies, though, stems, I assume, from no one else having encountered this. The general rule of thumb around here is "don't answer unless you think you actually know what you're talking about." Not getting a response and being ignored are two completely differnt things around here. The wiser heads are probably scratching their chins over this as we speak, and as soon as someone has an answer for you, they'll chime in. In the mean time, here are a couple of things I would look into: 1) Download the Bundle::CPAN tarball from CPAN and install it manually (untar, make, make install, etc., as for any other source build on a unix system). 2) Try cpanplus, which should be installed as part of the default installation. The cpan until is being pahased out anyway, so we're all going to have to get comfortable with cpanplus at some point. 3) Build modules you can't wait for by hand. 4) And this is probably the most importnat point, make sure your problem is really with perl. While it's possible that cpan has some strange memory leak, this sounds, as Owen said in his first response, suspiciously like a quota problem. All the memory in the world won't help you if Perl can't access it. Also do a quick df and make sure that there's plenty of room in both your build directory and your installation directory. The 20mb limit is just what cpan will leave lying around in the cache when it exits in case you want to quickly rebuild something without downloading it again. Some large modules, like any large source project, can use upwards of a gig of disc space ad certain points in the build process. make sure you have room on the volume where .cpan resides for the source of whatever module your installing and its uninstalled dependencies, the compiled binaries of whatever you're trying to install and its dependencies, and a reasonable amount of room for temporary build files. how much space you need depends on the specific modules, but I suspect some may need up to 2x the size of the fnial compiled binaries. I've never really looked at how most people handle XS builds, but in smoe C circles, compiling to a.out, cping a.out to the binary name, and then rming a.out is a pretty standard practice. 5) Look into other changes you've made to your system lately. Are you having trouble building anything else? Have you upgraded gcc recently? Are other applications having trouble allocating resources? 6) Show us the command line or script you're using to install, and the complete error message. This really sounds like a resource allocation issue. There's no earthly reason for the beahior you describe. Each time cpan starts, it's a new instance; it shouldn't matter what you've done with it before. One last thought: you said this was for web services. You're not trying to manage your modules through a web interface running under mod_perl, are you? HTH, -- jay -------------------------------------------------- This email and attachment(s): [ ] blogable; [ x ] ask first; [ ] private and confidential daggerquill [at] gmail [dot] com http://www.tuaw.com http://www.dpguru.com http://www.engatiki.org values of β will give rise to dom!
