Re: gd croaking
On Friday, October 18, 2002, at 12:41 AM, Puneet Kishor wrote: You are correct. I did have a wrong idea about cpan's functioning and capabilities, and hence, my rant _was_ misguided. As I said, though - What you said wasn't wrong, just a bit off as to where the blame for the problem should be placed. Your complaint was perfectly valid. The Makefile for the GD module should check for the correct version of libgd. That isn't a problem with CPAN, but it *is* a problem, and you were right to complain about it. but they lied when they said it would be easy. For the most part, it is. But, every rule has its exceptions, and judging by your posts here, you've had the bad luck to have encountered quite a few of the exceptions to this rule, one after another. So hang in there - it usually *is* easier than what you've seen in the past few weeks. I must say, venting frustration in the ether of a mailing list is a lot better than shoving my head through my iBook's lcd panel. Cheaper, too! :-) sherm--
Re: gd croaking
On Thursday, October 17, 2002, at 09:11 AM, Puneet Kishor wrote: Anyway, I also found the following right at the top of the Makefile warn NOTICE: This module requires libgd 2.0.1 or higher.\n; warn For earlier versions of libgd, use GD version 1.43.\n; huh! so, cpan is not that idiot-proof. Nor is it a mind reader. CPAN simply acts on dependencies that have been listed by module authors, no more, no less. Would have been nice if it had figured out that I had libgd 1.8.4 Yeah, that would be nice. But, that's not how CPAN works. It doesn't deduce or figure out anything at all - it reads the list of dependencies provided by the module author, and acts upon them. That works pretty well, when only Perl modules are involved - but it breaks down when external libraries are involved. A major problem with external library dependencies is that each library has its own way of reporting its version. Some, such as libgnome, provide a config script - gnome-config --version. Others, such as libxml, use different names to distinguish incompatible libraries - libxml vs. libxml2. Others provide a function in the library itself, that reports the version. Because the methods used to detect library versions aren't consistent, it cannot be done by the CPAN module - it has to be managed by individual module authors and built into module Makefiles. (the latest stable version) and gotten the appropriate GD for me. Interestingly, libgd 2.0.1 is still beta, and yet, cpan insists on installing a beta-dependent software. CPAN didn't insist on anything. It did exactly what you asked it to do - it attempted to install the latest version. Had you read the readme - something that CPAN makes very easy, by the way, all you need to do is enter readme ModuleName - you could have seen that the latest version is not what you wanted, without even having to download the full package. With all due respect, I feel that your rant about CPAN is misguided. You seem to have a rather unrealistic idea of what CPAN does and how it does it. It's not a comprehensive package manager like Fink or BSD's Ports. It's simply a tool that makes installing most modules more convenient. On the other hand, even though you've chosen the wrong target for venting your frustration, you do have a legitimate cause for complaint. The question is, why didn't the Makefile for GD.pm look for the version of libgd that it needed, and complain when it failed to detect it? The CPAN module cannot be realistically expected to figure out library dependencies, but it's not unreasonable to expect such a sanity check in the GD.pm Makefile. Btw, am I the only one who finds the error messages streaming off my terminal at 300 mph while doing the make, build dance useless? I find it easier to do the build, test, and install steps separately. To do that in the CPAN shell, just use the build Module, test Module commands before issuing the install Module command. sherm--
Re: gd croaking
On Thursday, October 17, 2002, at 11:21 PM, Sherm Pendley wrote: On Thursday, October 17, 2002, at 09:11 AM, Puneet Kishor wrote: Anyway, I also found the following right at the top of the Makefile warn NOTICE: This module requires libgd 2.0.1 or higher.\n; warn For earlier versions of libgd, use GD version 1.43.\n; huh! so, cpan is not that idiot-proof. Nor is it a mind reader. CPAN simply acts on dependencies that have been listed by module authors, no more, no less. Would have been nice if it had figured out that I had libgd 1.8.4 Yeah, that would be nice. But, that's not how CPAN works. It doesn't deduce or figure out anything at all - it reads the list of dependencies provided by the module author, and acts upon them. That works pretty well, when only Perl modules are involved - but it breaks down when external libraries are involved. A major problem with external library dependencies is that each library has its own way of reporting its version. Some, such as libgnome, provide a config script - gnome-config --version. Others, such as libxml, use different names to distinguish incompatible libraries - libxml vs. libxml2. Others provide a function in the library itself, that reports the version. Because the methods used to detect library versions aren't consistent, it cannot be done by the CPAN module - it has to be managed by individual module authors and built into module Makefiles. (the latest stable version) and gotten the appropriate GD for me. Interestingly, libgd 2.0.1 is still beta, and yet, cpan insists on installing a beta-dependent software. CPAN didn't insist on anything. It did exactly what you asked it to do - it attempted to install the latest version. Had you read the readme - something that CPAN makes very easy, by the way, all you need to do is enter readme ModuleName - you could have seen that the latest version is not what you wanted, without even having to download the full package. With all due respect, I feel that your rant about CPAN is misguided. You seem to have a rather unrealistic idea of what CPAN does and how it does it. You are correct. I did have a wrong idea about cpan's functioning and capabilities, and hence, my rant _was_ misguided. Yes, the Makefile.PL had confusing information... (btw, thanks for the tip on readme)... readme GD provides info that is different from Makefile.PL (the latter mentions a seemingly non-existent GD-1.43) ... On the other hand, even though you've chosen the wrong target for venting your frustration ... I guess frustration is the right word. To date, except for MoveableType I have not had a single easy and successful configure,make,install experience. For most things I don't even know why they happen the way they do. And yes, there is documentation for everything, but they lied when they said it would be easy. Maybe I am a poster child for mac and *nix worlds colliding, and I shudder when I think of others trying to conquer this because I am actually fairly computer literate (well, someone pays me for programming, though, not for programming perl... that would not be a good deal for my employers...). Anyway, apologies for the ranting... although, I must say, venting frustration in the ether of a mailing list is a lot better than shoving my head through my iBook's lcd panel. ;-) Puneet.
Re: gd croaking
You could always tee sdtout/stderr to a log file for later review. 21 | tee -a somelogfile Puneet Kishor wrote: Btw, am I the only one who finds the error messages streaming off my terminal at 300 mph while doing the make, build dance useless? I mean, I can't even read them, and by the time I scroll up to read the buffer runoff, make is merrily proceeding along its erroneous ways. Strange are unix ways... less is more... ;-)
Re: gd croaking
Thanks for the tip, however, I _need_ to use gd and perl together. And, I am not even talking about GD.pm. I need the pure gd library for a perl module I have. Seems perl 5.6.0 now has issues with gd as I built it. funny that the same gd, built exactly the same way on MacOS X 10.1.15 worked just fine with perl 5.6.0. Now it has issues. On Thursday, October 10, 2002, at 09:57 PM, Dave Gomez wrote: Puneet, Think I had same issues, and gave up and used gnuplot instead for some graph creation, as it does put out graphs like the ones I use on my site well (http://www.dkgomez.com/cgi-bin/housetemp.pl). Think I used fink to do the install of gnuplot Dave Gomez On 10/10/02 2:27 PM, Puneet Kishor [EMAIL PROTECTED] wrote: Ok, here's some more info that I was able to put together. I built gd and supporting libraries using gcc 3.1. To build another program (that actually eventually generates a perl module), I had to revert to gcc 2.x. I, then, reverted back to gcc 3.x and built the perl specific module. Running my perl scripts hence produces the errors below. The dyld: perl Undefined symbols: portion indicates there might be some binary incompatibility. Between what and what though? Is there a way I can test this? (I guess, in a manner of speaking, I did test it and learned it is incompatible :-( ) Puneet Kishor wrote: Folks, I haven't messed with the OS at all. I am using the Perl 5.6.0 that comes with OS X 10.2. I built gd 1.8.4 using Scott Anguish's directions on stepwise (as I have done before), and that worked just as expected. Then I built a specific perl module that helps makes maps (used to work fine on 10.1.whatever. I run my scripts unchanged, and I get the following in the apache error_log. Seems like gd is not happy. Without any further info to share (I really don't know what else to offer), can anyone shed some light on the following, or guide me to someplace I can find answers? Many thanks. Puneet. % tail -f /var/log/httpd/error_log dyld: perl Undefined symbols: _gdFontGiant _gdFontLarge _gdFontMediumBold _gdFontSmall _gdFontTiny _gdImageArc _gdImageColorAllocate _gdImageColorTransparent _gdImageCopy _gdImageCopyMerge _gdImageCopyResized _gdImageCreate _gdImageCreateFromJpeg _gdImageCreateFromPng _gdImageDestroy _gdImageFillToBorder _gdImageFilledPolygon _gdImageFilledRectangle _gdImageInterlace _gdImageJpeg _gdImageJpegPtr _gdImageLine _gdImagePng _gdImagePngPtr _gdImagePolygon _gdImageRectangle _gdImageSetBrush _gdImageSetPixel _gdImageSetStyle _gdImageSetTile _gdImageString _gdImageStringFT _gdImageWBMP _gdImageWBMPPtr [Thu Oct 10 11:00:46 2002] [error] [client 127.0.0.1] Premature end of script headers: /Users/pkishor/Sites/bims/index.pl
Re: gd croaking
Ok, here's some more info that I was able to put together. I built gd and supporting libraries using gcc 3.1. To build another program (that actually eventually generates a perl module), I had to revert to gcc 2.x. I, then, reverted back to gcc 3.x and built the perl specific module. Running my perl scripts hence produces the errors below. The dyld: perl Undefined symbols: portion indicates there might be some binary incompatibility. Between what and what though? Is there a way I can test this? (I guess, in a manner of speaking, I did test it and learned it is incompatible :-( ) Puneet Kishor wrote: Folks, I haven't messed with the OS at all. I am using the Perl 5.6.0 that comes with OS X 10.2. I built gd 1.8.4 using Scott Anguish's directions on stepwise (as I have done before), and that worked just as expected. Then I built a specific perl module that helps makes maps (used to work fine on 10.1.whatever. I run my scripts unchanged, and I get the following in the apache error_log. Seems like gd is not happy. Without any further info to share (I really don't know what else to offer), can anyone shed some light on the following, or guide me to someplace I can find answers? Many thanks. Puneet. % tail -f /var/log/httpd/error_log dyld: perl Undefined symbols: _gdFontGiant _gdFontLarge _gdFontMediumBold _gdFontSmall _gdFontTiny _gdImageArc _gdImageColorAllocate _gdImageColorTransparent _gdImageCopy _gdImageCopyMerge _gdImageCopyResized _gdImageCreate _gdImageCreateFromJpeg _gdImageCreateFromPng _gdImageDestroy _gdImageFillToBorder _gdImageFilledPolygon _gdImageFilledRectangle _gdImageInterlace _gdImageJpeg _gdImageJpegPtr _gdImageLine _gdImagePng _gdImagePngPtr _gdImagePolygon _gdImageRectangle _gdImageSetBrush _gdImageSetPixel _gdImageSetStyle _gdImageSetTile _gdImageString _gdImageStringFT _gdImageWBMP _gdImageWBMPPtr [Thu Oct 10 11:00:46 2002] [error] [client 127.0.0.1] Premature end of script headers: /Users/pkishor/Sites/bims/index.pl
Re: gd croaking
Puneet, Think I had same issues, and gave up and used gnuplot instead for some graph creation, as it does put out graphs like the ones I use on my site well (http://www.dkgomez.com/cgi-bin/housetemp.pl). Think I used fink to do the install of gnuplot Dave Gomez On 10/10/02 2:27 PM, Puneet Kishor [EMAIL PROTECTED] wrote: Ok, here's some more info that I was able to put together. I built gd and supporting libraries using gcc 3.1. To build another program (that actually eventually generates a perl module), I had to revert to gcc 2.x. I, then, reverted back to gcc 3.x and built the perl specific module. Running my perl scripts hence produces the errors below. The dyld: perl Undefined symbols: portion indicates there might be some binary incompatibility. Between what and what though? Is there a way I can test this? (I guess, in a manner of speaking, I did test it and learned it is incompatible :-( ) Puneet Kishor wrote: Folks, I haven't messed with the OS at all. I am using the Perl 5.6.0 that comes with OS X 10.2. I built gd 1.8.4 using Scott Anguish's directions on stepwise (as I have done before), and that worked just as expected. Then I built a specific perl module that helps makes maps (used to work fine on 10.1.whatever. I run my scripts unchanged, and I get the following in the apache error_log. Seems like gd is not happy. Without any further info to share (I really don't know what else to offer), can anyone shed some light on the following, or guide me to someplace I can find answers? Many thanks. Puneet. % tail -f /var/log/httpd/error_log dyld: perl Undefined symbols: _gdFontGiant _gdFontLarge _gdFontMediumBold _gdFontSmall _gdFontTiny _gdImageArc _gdImageColorAllocate _gdImageColorTransparent _gdImageCopy _gdImageCopyMerge _gdImageCopyResized _gdImageCreate _gdImageCreateFromJpeg _gdImageCreateFromPng _gdImageDestroy _gdImageFillToBorder _gdImageFilledPolygon _gdImageFilledRectangle _gdImageInterlace _gdImageJpeg _gdImageJpegPtr _gdImageLine _gdImagePng _gdImagePngPtr _gdImagePolygon _gdImageRectangle _gdImageSetBrush _gdImageSetPixel _gdImageSetStyle _gdImageSetTile _gdImageString _gdImageStringFT _gdImageWBMP _gdImageWBMPPtr [Thu Oct 10 11:00:46 2002] [error] [client 127.0.0.1] Premature end of script headers: /Users/pkishor/Sites/bims/index.pl
