whoops!
Hey all, I think I was installing libwww from CPAN and mindlessly said yes to a couple of optional installs. Seems it overwrote my /usr/bin/head with a perl module to interpret http HEAD calls. Not fun! So I've had a hell of a time looking for a source install, a package, something, somewhere that had the head program, since a lot of install scripts (namely, mod_perl) rely on it to do business. Anyone know how I can fix this without hosing my entire freakin system? I' ve tried reinstalling the BSD Subsystem package from my OSX CD, no dice there. Suggestions, please? Thanks, Mark
Re: whoops!
On Wednesday, April 3, 2002, at 11:07 am, Mark Setzer wrote: Hey all, I think I was installing libwww from CPAN and mindlessly said yes to a couple of optional installs. Seems it overwrote my /usr/bin/head with a perl module to interpret http HEAD calls. Not fun! So I've had a hell of a time looking for a source install, a package, something, somewhere that had the head program, since a lot of install scripts (namely, mod_perl) rely on it to do business. Anyone know how I can fix this without hosing my entire freakin system? I' ve tried reinstalling the BSD Subsystem package from my OSX CD, no dice there. Suggestions, please? Thanks, Mark I actually just copied the head binary straight from the MacOSX install CD (i.e. from the system that you boot from on that CD, not the installer files). Seems to work fine. Perhaps the installer refuses to overwrite /usr/ bin/head if it already exists? Tim
mod_perl compile errors.
One more, eh? Sorry if this is an already-answered question, but, I'm trying to compile mod_perl and have hit the following snag: env LD_RUN_PATH=/System/Library/Perl/darwin/CORE cc -c -I.. -I/System/Library/Perl/darwin/CORE -I../os/unix -I../include -DDARWIN -DMOD_PERL -DUSE_PERL_SSI -pipe -fno-common -DHAS_TELLDIR_PROTOTYPE -fno-strict-aliasing -I/usr/local/include -DUSE_HSREGEX -DNO_DL_NEEDED -pipe -fno-common -DHAS_TELLDIR_PROTOTYPE -fno-strict-aliasing -I/usr/local/include `../apaci` alloc.c alloc.c: In function `spawn_child_core': alloc.c:2291: `STDOUT_FILENO' undeclared (first use in this function) alloc.c:2291: (Each undeclared identifier is reported only once alloc.c:2291: for each function it appears in.) alloc.c:2297: `STDIN_FILENO' undeclared (first use in this function) alloc.c:2303: `STDERR_FILENO' undeclared (first use in this function) make[4]: *** [alloc.o] Error 1 make[3]: *** [subdirs] Error 1 make[2]: *** [build-std] Error 2 make[1]: *** [build] Error 2 make: *** [apaci_httpd] Error 2 Anyone seen this before? I'm running OSX 10.1.3, it's mod_perl 1.26 compiling against apache 1.3.24. Any help appreciated. Thanks, Mark
Re: mod_perl compile errors.
I have question (out of ignorance, if anything) -- why on earth would you want to build and compile mod_perl yourself, when you can let CPAN do all the nonsense? I let CPAN do it, and I am wondering if I missed out on something? Needless to say, I know diddly about build and make and -DUSE... you get the picture. pk/ On Wednesday, April 3, 2002, at 04:36 AM, Mark Setzer wrote: One more, eh? Sorry if this is an already-answered question, but, I'm trying to compile mod_perl and have hit the following snag: env LD_RUN_PATH=/System/Library/Perl/darwin/CORE cc -c -I.. -I/System/Library/Perl/darwin/CORE -I../os/unix -I../include -DDARWIN -DMOD_PERL -DUSE_PERL_SSI -pipe -fno-common -DHAS_TELLDIR_PROTOTYPE -fno-strict-aliasing -I/usr/local/include -DUSE_HSREGEX -DNO_DL_NEEDED -pipe -fno-common -DHAS_TELLDIR_PROTOTYPE -fno-strict-aliasing -I/usr/local/include `../apaci` alloc.c alloc.c: In function `spawn_child_core': alloc.c:2291: `STDOUT_FILENO' undeclared (first use in this function) alloc.c:2291: (Each undeclared identifier is reported only once alloc.c:2291: for each function it appears in.) alloc.c:2297: `STDIN_FILENO' undeclared (first use in this function) alloc.c:2303: `STDERR_FILENO' undeclared (first use in this function) make[4]: *** [alloc.o] Error 1 make[3]: *** [subdirs] Error 1 make[2]: *** [build-std] Error 2 make[1]: *** [build] Error 2 make: *** [apaci_httpd] Error 2 Anyone seen this before? I'm running OSX 10.1.3, it's mod_perl 1.26 compiling against apache 1.3.24. Any help appreciated. Thanks, Mark
Re: whoops!
Tim, Mark, Question -- if/when I do find head on the OS X CD, where should I put it? I can't put it back in /usr/bin because it will then overwrite HEAD that is present there now, no? corollary -- why is head so important? isn't it just the opposite of tail? I use tail once in a while, but unless the system uses head, what do I suffer if its not there? Tia, pk/ On Wednesday, April 3, 2002, at 04:08 AM, Tim Rayner wrote: On Wednesday, April 3, 2002, at 11:07 am, Mark Setzer wrote: Hey all, I think I was installing libwww from CPAN and mindlessly said yes to a couple of optional installs. Seems it overwrote my /usr/bin/head with a perl module to interpret http HEAD calls. Not fun! So I've had a hell of a time looking for a source install, a package, something, somewhere that had the head program, since a lot of install scripts (namely, mod_perl) rely on it to do business. Anyone know how I can fix this without hosing my entire freakin system? I' ve tried reinstalling the BSD Subsystem package from my OSX CD, no dice there. Suggestions, please? Thanks, Mark I actually just copied the head binary straight from the MacOSX install CD (i.e. from the system that you boot from on that CD, not the installer files). Seems to work fine. Perhaps the installer refuses to overwrite /usr/ bin/head if it already exists? Tim
Re: Perl/Tk on Mac os X
Hi All, Does anyone have any updated information on perl/Tk for OS X? Most of my stuff at work uses perl/Tk and I was over-joyed to install Tk on my Mac. To my chagrin it crashes exactly like described below. Is there an OS X -compatible version available now? Does anyone know what causes this problem? I'm assuming it's a C thing... -Aaron On Wednesday 30 January 2002 01:25 pm, Rick Frankel wrote: On Wed, Jan 30, 2002 at 10:33:21AM -0500, aaron wrote: I have followed the same procedure as you and I also get a bus error with menus. In fact, the widget demo that comes with perl/Tk gives a bus error for almost every part of its interface. Are we the only two people having this problem? If so, is there something we can do to fix this? Most of my Nope, you're not. I think this thread has passed this list before. It's not just menus, hovering over any gui component causes a crash. Haven't had time to try and track down the problem though... rick
Re: whoops!
On Wed, 3 Apr 2002, Puneet Kishor wrote: Question -- if/when I do find head on the OS X CD, where should I put it? I can't put it back in /usr/bin because it will then overwrite HEAD that is present there now, no? * Find it on the CD, let's say it's at /Volumes/MacOSX/usr/bin/head * move the LWP head to a better name, let's say /usr/bin/lwp-head * copy /Volumes/MacOSX/usr/bin/head to /usr/bin/head System restored, conflict resolved. corollary -- why is head so important? It's useful for viewing slices of an input stream or file. Yes it is the opposite of tail, and in tandem the two can help solve problems like, say, (contrived example) finding the median sized file in a directory: % ls -s1 | sort | wc -l 51 % ls -s1 | sort | head -26 | tail -1 42 echelon_terms % Yes that's kind of an exotic example, but it's the first one that comes to mind that shows how you can pass output from head (the first subset of a list of lines) to tail (to get the last sub-subset of the head list) in order to slice into the middle of a larger set. Plus, more simply, they're just not the same. /usr/bin/head gives you the beginning of input; /usr/bin/tail gives you the end of input. They are complementary, yes, but they do have different roles uses. Anyway, if you're not normally slicing dicing files streams, then you can probably live without filters like this, but they can be very useful if you know how to manipulate them. And as you point out, even if you don't use them directly, other applications might assume that the tools are available fail if they're not. So it's worth fixing. -- Chris Devers[EMAIL PROTECTED] Apache / mod_perl / http://homepage.mac.com/chdevers/resume/ More war soon. You know how it is.-- mnftiu.cc
Re: whoops!
thanks Chris, for a lovely explanation. This is the kind of explanation us MacOS-newbies understand. You should write a Perl for MacOS X book in the tradition of Randal's llama book. I'll buy it. Btw, one quickie -- move the LWP head to a better name, let's say /usr/bin/lwp-head by LWP head, I am assuming you are referring to HEAD, no? pk/ On Wednesday, April 3, 2002, at 09:04 AM, Chris Devers wrote: On Wed, 3 Apr 2002, Puneet Kishor wrote: Question -- if/when I do find head on the OS X CD, where should I put it? I can't put it back in /usr/bin because it will then overwrite HEAD that is present there now, no? * Find it on the CD, let's say it's at /Volumes/MacOSX/usr/bin/head * move the LWP head to a better name, let's say /usr/bin/lwp-head * copy /Volumes/MacOSX/usr/bin/head to /usr/bin/head System restored, conflict resolved. corollary -- why is head so important? It's useful for viewing slices of an input stream or file. Yes it is the opposite of tail, and in tandem the two can help solve problems like, say, (contrived example) finding the median sized file in a directory: % ls -s1 | sort | wc -l 51 % ls -s1 | sort | head -26 | tail -1 42 echelon_terms % Yes that's kind of an exotic example, but it's the first one that comes to mind that shows how you can pass output from head (the first subset of a list of lines) to tail (to get the last sub-subset of the head list) in order to slice into the middle of a larger set. Plus, more simply, they're just not the same. /usr/bin/head gives you the beginning of input; /usr/bin/tail gives you the end of input. They are complementary, yes, but they do have different roles uses. Anyway, if you're not normally slicing dicing files streams, then you can probably live without filters like this, but they can be very useful if you know how to manipulate them. And as you point out, even if you don't use them directly, other applications might assume that the tools are available fail if they're not. So it's worth fixing. -- Chris Devers[EMAIL PROTECTED] Apache / mod_perl / http://homepage.mac.com/chdevers/resume/ More war soon. You know how it is.-- mnftiu.cc
Re: Perl/Tk on Mac os X
On Wed, Apr 03, 2002 at 09:57:48AM -0500, aaron wrote: Hi All, Does anyone have any updated information on perl/Tk for OS X? Most of my stuff at work uses perl/Tk and I was over-joyed to install Tk on my Mac. To my chagrin it crashes exactly like described below. Is there an OS X -compatible version available now? Does anyone know what causes this problem? I'm assuming it's a C thing... Whoops. I guess I should have followed up on this... Anyway, via macintouch comes this link: http://www.lehigh.edu/~sol0/Macintosh/X/ptk/ the short of it is that -03 optimization breaks perl/tk. Here's the relevant excerpt from the above on the solution: * Install the modified dynamic loader per http://www.lehigh.edu/Macintosh/X/ptk/dyld-tk. * Now compile Tk800.023. The caveat: you cannot use -O3, which is the default, determined from how Perl itself was compiled. Here's the trick as described by Michael Doster (who made the dyld mods described above): Under the pTk source directory edit the file Tk/MMutil.pm. In the subroutine cflags make the following change at the end: $_ .= \nOPTIMIZE=\n; $_; } # end subroutine cflags. BTW, personally tested and used (I can't live w/o -d:ptkdb :) rick
HEAD to head (was Re: whoops)
(sorry Chris, you might get two copies of this... I forgot to put the Subject in the first one so onion.perl.org sent it back to me... I would like the answer to this, as well as have it archived in the mailing-list archives. Hence, resending it) Chris Devers wrote: Btw, one quickie -- move the LWP head to a better name, let's say /usr/bin/lwp-head by LWP head, I am assuming you are referring to HEAD, no? Yes, exactly. which begs the next obvious question -- if I rename HEAD to lwp-head, then won't other Perl programs that depend upon HEAD break? They will be looking for HEAD which is now lwp-head. In a case of a rarer condition, if there are any HFS-style case-blind applications that might want to call head, they will end up calling HEAD. pk/ -- Puneet Kishor [EMAIL PROTECTED] www.geoanalytics.com GeoAnalytics, Inc. 1716 Fordem Ave Madison WI 53704
Re: your mail
On Wed, 3 Apr 2002, PK Eidesis wrote: Chris Devers wrote: if I rename HEAD to lwp-head, then won't other Perl programs that depend upon HEAD break? They will be looking for HEAD which is now lwp-head. Maybe, but I wouldn't worry about it. LWP's HEAD is an optional program that Perl developers shouldn't rely upon -- it's just a throw-in that can make some command line stuff easier. If you look at the source, it should be a short little script that just calls $lwp-head( $url ) [or something to that effect]. If someone wants to put that functionality in a program, it's more efficient reliable to just put that statement in directly, rather than depending on the user to have installed this little helper program (with the right name, in the right directory, set as executable, etc). To hell with all that, just have you script use LWP; my $lwp = new LWP; my $head = $lwp-head( $url ) or whatever and be done with it. :) LWP just offers HEAD as a freebie /slash/ demo of how to use the library, but most users can get the same result with lynx --head $site or opening up telnet $site 80\n\nHEAD\n\n, and Perl scripts should never rely on HEAD being available or mandatory. There's always a better alternative, at least in practice. In a case of a rarer condition, if there are any HFS-style case-blind applications that might want to call head, they will end up calling HEAD. and get the LWP program when they wanted the stream filter. This is a much more likely broken problem. -- Chris Devers[EMAIL PROTECTED] Apache / mod_perl / http://homepage.mac.com/chdevers/resume/ More war soon. You know how it is.-- mnftiu.cc
is my perl tarnished?
[careful, cross-posted to two lists] Fink wants an update. I try to let it. Here's what I get: dpkg-deb -b root-fink-0.9.10-1 /sw/fink/dists/unstable/main/binary-darwin-powerpc/base dpkg-deb: building package `fink' in `/sw/fink/dists/unstable/main/binary-darwin-powerpc/base/fink_0.9.10-1_darwin-powerpc.deb'. ln -sf /sw/fink/dists/unstable/main/binary-darwin-powerpc/base/fink_0.9.10-1_darwin-powerpc.deb /sw/fink/debs/ rm -rf /sw/src/root-fink-0.9.10-1 dpkg -i /sw/fink/dists/unstable/main/binary-darwin-powerpc/base/fink_0.9.10-1_darwin-powerpc.deb Reading version This is Mac OS X 10.1.3 (Reading database ... 63404 files and directories currently installed.) Preparing to replace fink 0.9.9a-1 (using .../fink_0.9.10-1_darwin-powerpc.deb) ... Unpacking replacement fink ... Setting up fink (0.9.10-1) ... Re-executing fink to use the new version... Reading package info... dyld: perl5.6.0 Undefined symbols: _PerlIO_getc _PerlIO_putc _Perl_PerlIO_read _Perl_PerlIO_write _Perl_sv_2pv_flags Reading package info... dyld: perl5.6.0 Undefined symbols: _PerlIO_getc _PerlIO_putc _Perl_PerlIO_read _Perl_PerlIO_write _Perl_sv_2pv_flags at which point selfupdate fails and I'm back at my prompt. I *did* have a misfired Perl upgrade a month or two ago, and this is the same symptoms that that gave me when trying to do things like use CPAN.pm. So on one hand, this isn't a total surprise to me by now. The bigger question is, how serious is this problem (both for Fink and for Perl), and how can I get Perl to recognize these symbols? Does anyone know if OSX 10.2 is going to have a Perl upgrade (in which case I'll try to sweat this out), or if Perl 5.8 will be out soon (in which case I'll try to sweat this out), or if those upgrades aren't going to be ready any time soon and even when they are ready this problem is going to keep them from working right (in which case I have little choice but to try to work this out now). Sorry, I think this was a little more vague than I meant for it to be... :/ -- Chris Devers[EMAIL PROTECTED] Apache / mod_perl / http://homepage.mac.com/chdevers/resume/ More war soon. You know how it is.-- mnftiu.cc
Re: mod_perl compile errors.
symptom of a bigger problem. all CPAN does is download and compile the same source that i was using, with fewer configuration options. i'd like to be able to freely configure mod_perl for use with my website. however. i force-installed Bundle::Apache, and httpd refuses to load. i'm not getting any error messages (?) in my system log, but i've configured my httpd.conf to load the module at /usr/libexec. as soon as i comment the appropriate lines out again, it loads freely, even though CPAN (and a quick look confirms) that it was installed without issue. damn. any suggestions? -Mark On Wednesday, April 3, 2002, at 09:42 AM, Puneet Kishor wrote: I have question (out of ignorance, if anything) -- why on earth would you want to build and compile mod_perl yourself, when you can let CPAN do all the nonsense? I let CPAN do it, and I am wondering if I missed out on something? Needless to say, I know diddly about build and make and -DUSE... you get the picture. pk/
Re: HEAD to head (was Re: whoops)
On Thursday, April 4, 2002, at 04:38 AM, PK Eidesis wrote: (sorry Chris, you might get two copies of this... I forgot to put the Subject in the first one so onion.perl.org sent it back to me... I would like the answer to this, as well as have it archived in the mailing-list archives. Hence, resending it) This will be about the umpteenth time it gets put in the archives. Not necessarily a bad thing, but this is well-worn ground. if I rename HEAD to lwp-head, then won't other Perl programs that depend upon HEAD break? They will be looking for HEAD which is now lwp-head. Yeah, but I know of no such programs. Calling HEAD from a command line isn't a very clean thing to do, Perl programs could just call the LWP routines directly. In a case of a rarer condition, if there are any HFS-style case-blind applications that might want to call head, they will end up calling HEAD. Check this out, on my system: [junior:~] ken% which head /usr/bin/head [junior:~] ken% which HEAD /usr/local/bin/HEAD I've had it this way for almost a year, and I've had zero problems with it. -Ken
Re: is my perl tarnished?
Chris,
It's having trouble loading the binary part of some perl module. You
can tell because of the dyld: bit. It doesn't say which module is the
problem, though, but once you find it you should be able to just
reinstall that module.
Finkos, what's the proper way to increase verbosity, or hook into
$SIG{__DIE__}, to tell what module is the problem?
Chris, I'm assuming your perl installation works well normally, yes?
On Thursday, April 4, 2002, at 08:22 AM, Chris Devers wrote:
On Wed, 3 Apr 2002, Chris Devers wrote:
[careful, cross-posted to two lists]
Followup / footnote:
Now when trying to run Fink's selfupdate, I get:
[localhost Wed 5:01:46pm ~]% fink -y selfupdate
many, many normal output lines from the CVS
synchronization
cvs server: Updating dists/unstable/main/finkinfo/x11-wm
Reading package info...
dyld: perl5.6.0 Undefined symbols:
_PerlIO_getc
_PerlIO_putc
_Perl_PerlIO_read
_Perl_PerlIO_write
_Perl_sv_2pv_flags
Reading package info...
dyld: perl5.6.0 Undefined symbols:
_PerlIO_getc
_PerlIO_putc
_Perl_PerlIO_read
_Perl_PerlIO_write
_Perl_sv_2pv_flags
[localhost Wed 5:11:24pm ~]%
And... that appears to be it.
Any suggestions on how I might go about fixing this?
:(
--
Chris Devers[EMAIL PROTECTED]
Apache / mod_perl / http://homepage.mac.com/chdevers/resume/
More war soon. You know how it is.-- mnftiu.cc
-Ken
Re: is my perl tarnished?
On Thu, 4 Apr 2002, Ken Williams wrote:
It's having trouble loading the binary part of some perl module.
Well that's actually a pretty useful insight, thank you. I kept thinking
it was some exotic condition within Perl itself, but was having a hard
time thinking of what it could be why it only happened sporadically. Of
course it makes sense for it to be a corrupted library or something along
those lines ...but which?
The two situations in which I've been able to reliably reproduce this is
[a] now, when using Fink, and [b] earlier when trying to use CPAN.pm:
[localhost Wed 6:59:22pm bin]% sudo cpan
cpan
cpan ?
Display Information
command argument description
[[snip -- suffice to say, asking for help works just fine]]
cpan i LWP
dyld: perl5.6.0 Undefined symbols:
_PerlIO_getc
_PerlIO_putc
_Perl_PerlIO_read
_Perl_PerlIO_write
_Perl_sv_2pv_flags
[localhost Wed DING! bin]%
So, both Fink and CPAN.pm's search mechanism are calling the same broken
routine. That's a start anyway, now I've got to go whittle some more...
You can tell because of the dyld: bit. It doesn't say which module is
the problem, though, but once you find it you should be able to just
reinstall that module.
Thanks :)
Finkos, what's the proper way to increase verbosity, or hook into
$SIG{__DIE__}, to tell what module is the problem?
You can set Verbose: true in /sw/etc/fink.conf, but that's what I'm
using here and you saw the output that I'm getting. I wonder if adding a
use warnings would help; hrm, guess not. Carp maybe? Coy? That would be
stress relief anyhow... :)
Chris, I'm assuming your perl installation works well normally, yes?
It works just fine 90% of the time, aside from locale warnings it works
well 99% of the time. But when it fails, it fails spectacularly... :/
--
Chris Devers[EMAIL PROTECTED]
Apache / mod_perl / http://homepage.mac.com/chdevers/resume/
More war soon. You know how it is.-- mnftiu.cc
Re: [Fink-users] Re: is my perl tarnished?
On Thursday, April 4, 2002, at 10:18 AM, Alexander Strange wrote:
On Wednesday, April 3, 2002, at 06:55 PM, Ken Williams wrote:
Finkos, what's the proper way to increase verbosity, or hook into
$SIG{__DIE__}, to tell what module is the problem?
man dyld
According to that man page, then, you should be able to set the
DYLD_PRINT_LIBRARIES environment variable to 1 or something to increase
verbosity. It would be nice to do this at the perl level, but the dyld
level should work fine.
-Ken
Re: [Fink-users] Re: is my perl tarnished?
On Thu, 4 Apr 2002, Ken Williams wrote:
On Thursday, April 4, 2002, at 10:18 AM, Alexander Strange wrote:
On Wednesday, April 3, 2002, at 06:55 PM, Ken Williams wrote:
Finkos, what's the proper way to increase verbosity, or hook into
$SIG{__DIE__}, to tell what module is the problem?
man dyld
According to that man page, then, you should be able to set the
DYLD_PRINT_LIBRARIES environment variable to 1 or something to
increase verbosity. It would be nice to do this at the perl
level, but the dyld level should work fine.
Cool, now we're getting somewhere...
[localhost Wed 7:27:54pm bin]% sudo cpan
loading libraries for image: sudo
loading library: /usr/lib/libSystem.B.dylib
loading libraries for image: /usr/lib/libSystem.B.dylib
loading libraries for image: perl5.6.0
loading library: /System/Library/Perl/darwin/CORE/libperl.dylib
loading library: /usr/lib/libSystem.B.dylib
loading libraries for image: /System/Library/Perl/darwin/CORE/libperl.dylib
loading libraries for image: /usr/lib/libSystem.B.dylib
loading libraries for image: /System/Library/Perl/darwin/auto/IO/IO.bundle
loading libraries for image: /System/Library/Perl/darwin/auto/Fcntl/Fcntl.bundle
loading libraries for image: /System/Library/Perl/darwin/auto/Opcode/Opcode.bundle
loading libraries for image: /Library/Perl/darwin/auto/Term/ReadKey/ReadKey.bundle
loading libraries for image: pwd
loading library: /usr/lib/libSystem.B.dylib
loading libraries for image: /usr/lib/libSystem.B.dylib
cpan i LWP
loading libraries for image: /Library/Perl/darwin/auto/Storable/Storable.bundle
dyld: perl5.6.0 Undefined symbols:
_PerlIO_getc
_PerlIO_putc
_Perl_PerlIO_read
_Perl_PerlIO_write
_Perl_sv_2pv_flags
[localhost Wed 7:28:05pm bin]%
So is it Storable.pm that's corrupted? Think it'll help to rebuild it?
--
Chris Devers[EMAIL PROTECTED]
Apache / mod_perl / http://homepage.mac.com/chdevers/resume/
More war soon. You know how it is.-- mnftiu.cc
Re: [Fink-users] Re: is my perl tarnished?
On Thursday, April 4, 2002, at 10:40 AM, Chris Devers wrote: loading libraries for image: /Library/Perl/darwin/auto/Storable/Storable.bundle dyld: perl5.6.0 Undefined symbols: _PerlIO_getc _PerlIO_putc _Perl_PerlIO_read _Perl_PerlIO_write _Perl_sv_2pv_flags Pow! Storable rears its ugly head again. So, isn't Storable.pm a core library? Can it be built the same way (./configure, make, make test, sudo make install) that others are? This doesn't mean rebuild Perl from scratch, I hope... Nope, Storable is a regular CPAN module, not in the core: [junior:~] ken% perldoc -l Storable /Library/Perl/darwin/Storable.pm (Unfortunately it's going in the core for 5.8, which does make some upgrade tasks like this harder if they don't keep the CPAN version current...) -Ken
Re: [Fink-users] Re: is my perl tarnished?
On Thu, 4 Apr 2002, Ken Williams wrote: Nope, Storable is a regular CPAN module, not in the core: So you have written, so it has been done. After downloading installing Storable.pm from CPAN, I've re-run fink selfupdate again. Snipping: Reading package info... loading libraries for image: pwd loading library: /usr/lib/libSystem.B.dylib loading libraries for image: /usr/lib/libSystem.B.dylib loading libraries for image: pwd loading library: /usr/lib/libSystem.B.dylib loading libraries for image: /usr/lib/libSystem.B.dylib loading libraries for image: pwd loading library: /usr/lib/libSystem.B.dylib loading libraries for image: /usr/lib/libSystem.B.dylib loading libraries for image: pwd loading library: /usr/lib/libSystem.B.dylib loading libraries for image: /usr/lib/libSystem.B.dylib loading libraries for image: pwd loading library: /usr/lib/libSystem.B.dylib loading libraries for image: /usr/lib/libSystem.B.dylib loading libraries for image: pwd loading library: /usr/lib/libSystem.B.dylib loading libraries for image: /usr/lib/libSystem.B.dylib loading libraries for image: /System/Library/Perl/darwin/auto/Fcntl/Fcntl.bundle loading libraries for image: /Library/Perl/darwin/auto/Storable/Storable.bundle Updating package index... done. Woohoo! That seems to have fixed it -- thanks! -- Chris Devers[EMAIL PROTECTED] Apache / mod_perl / http://homepage.mac.com/chdevers/resume/ More war soon. You know how it is.-- mnftiu.cc
Re: [Fink-users] Re: is my perl tarnished?
At 18:31 -0600 3/4/02, Chris Devers wrote: So is it Storable.pm that's corrupted? Think it'll help to rebuild it? I have some memory of reading something where Storable was used with a lowercase s, and so it was loaded (successfully, because of the case insensitivity) and then not found next time. Unfortunately, I can't find where I read this now. Also, when I had those dylb problems, it turned out the problem was in my library path settings. You might want to do a perl -V and compare it to the output below and check out any differences, particularly any in the paths. Enjoy, Peter. zany:~/unix% perl -V Summary of my perl5 (revision 5.0 version 6 subversion 1) configuration: Platform: osname=darwin, osvers=5.3, archname=darwin uname='darwin zany.peter.com.au 5.3 darwin kernel version 5.3: thu jan 24 22:06:02 pst 2002; root:xnuxnu-201.19.obj~1release_ppc power macintosh powerpc ' config_args='-des -Dfirstmakefile=GNUmakefile -Dldflags=-flat_namespace' hint=recommended, useposix=true, d_sigaction=define usethreads=undef use5005threads=undef useithreads=undef usemultiplicity=undef useperlio=undef d_sfio=undef uselargefiles=define usesocks=undef use64bitint=undef use64bitall=undef uselongdouble=undef Compiler: cc='cc', ccflags ='-pipe -fno-common -DHAS_TELLDIR_PROTOTYPE -fno-strict-aliasing -I/usr/local/include', optimize='-O3', cppflags='-pipe -fno-common -DHAS_TELLDIR_PROTOTYPE -fno-strict-aliasing -I/usr/local/include' ccversion='', gccversion='Apple devkit-based CPP 6.02', gccosandvers='' intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=4321 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=8 ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8 alignbytes=8, usemymalloc=n, prototype=define Linker and Libraries: ld='cc', ldflags ='-flat_namespace -L/usr/local/lib' libpth=/usr/local/lib /usr/lib libs=-lm -lc perllibs=-lm -lc libc=/System/Library/Frameworks/System.framework/System, so=dylib, useshrplib=true, libperl=libperl.dylib Dynamic Linking: dlsrc=dl_dyld.xs, dlext=bundle, d_dlsymun=undef, ccdlflags=' ' cccdlflags=' ', lddlflags='-flat_namespace -bundle -undefined suppress -L/usr/local/lib' Characteristics of this binary (from libperl): Compile-time options: USE_LARGE_FILES Built under darwin Compiled at 03/25/02 16:24:31 %ENV: PERL5LIB=/Users/peter/perl/Lib INC: /Users/peter/perl/Lib /System/Library/Perl/darwin /System/Library/Perl /Local/Library/Perl/darwin /Local/Library/Perl /Local/Library/Perl /Network/Library/Perl/darwin /Network/Library/Perl /Network/Library/Perl . zany:~/unix% -- http://www.interarchy.com/ ftp://ftp.interarchy.com/interarchy.hqx
CPAN sticklers
The CPAN shell can't seem to get past upgrading a few modules on my Pismo 400. Anyone able to get these working? : DB_File, Image::Magick, Net::Ping, Pod::LaTeX. DB_File 1.751.803 P/PM/PMQS/DB_File-1.803.tar.gz Interesting output: Note (probably harmless): No library found for -ldb ... t/db-btree*** malloc[14766]: error for object 0x173730: Incorrect check sum for freed object - object was probably modified after beeing freed; break at szone_error t/db-btreedubious Test returned status 0 (wstat 11, 0xb) ... t/db-recnoFAILED tests 61, 63, 65 Failed 3/149 tests, 97.99% okay ... make: *** [test_dynamic] Error 9 /usr/bin/make test -- NOT OK ... make test had returned bad status, won't install without force Image::Magick 5.41 5.43 J/JC/JCRISTY/PerlMagick-5.43.tar.gz Interesting output: Magick.xs:76: header file 'magick/api.h' not found ... [lots of resulting errors] ... make: *** [Magick.o] Error 1 /usr/bin/make -- NOT OK Net::Ping 2.02 2.14 B/BB/BBB/Net-Ping-2.14.tar.gz Interesting output: Warning: the following files are missing in your kit: Net-Ping.spec [oddly, the remaining messages point to a successful install -- but running 'r' in the cpan shell always turns up the same upgrade suggestion] Pod::LaTeX 0.53 0.54 T/TJ/TJENNESS/Pod-LaTeX-0.54.tar.gz Interesting output: [There are no suspicious messages during install. Install appears successful. But I remain at 0.53.] I'm stuck at the versions in the 2nd column, trying to upgrade to the versions in the 3rd column. -B...
