Re: Cannot load DBD::MySQL - Can't locate connnect.al
For one reason or another, I've decided to install DBI/DBD on my laptop. In attempting to do that, I've run across a few problems and questions. Here are the steps I followed to install mysql, DBI, and DBD::mysql successfully. I'm running OS X 10.3.4 on a PowerBook, and did this install just a few weeks ago. 1. Install the developer tools and enable the root user. 2. Download the mysql installer from http://dev.mysql.com/downloads/mysql/4.0.html. I used the 'Installer package (Mac OS X v10.3) Standard 4.0.20'. Install both the server and startup item (separate packages). Reboot, and the mysql server should be running. Check this with the Activity Monitor. The daemon 'mysqld' should be running with user 'mysql'. 3. Install DBI using CPAN. I start CPAN in terminal using the command 'sudo perl -MCPAN -e shell'. Once you have gone through the setup, and selected an assortment of CPAN servers, you will get the CPAN prompt. To install DBI, type the command 'install DBI'. This should go smoothly. It will be obvious if your install succeeded or failed. When using CPAN 'install', if any tests fail, no files are installed. 4. Before you proceed to install 'DBD::mysql', you will need to fix perl's Config.pm file, as explained by Edward Moy of Apple in a post to this list on October 15, 2003: We recently discovered the DBD::mysql problem as well. The patch is to edit /System/Library/Perl/5.8.1/darwin-thread-multi-2level/Config.pm, replacing: ld='MACOSX_DEPLOYMENT_TARGET=10.3 cc' with ld='env MACOSX_DEPLOYMENT_TARGET=10.3 cc' Unfortunately, this change is too late to get into Panther. --- Edward Moy Apple This is an essential step, as DBD::mysql will not compile until you make this patch. 5. Now, you can use CPAN to compile and install 'DBD::mysql'. Type the command 'install DBD::mysql' as with DBI. The software will compile successfully (after first compiling some prerequisites), and pass most of its tests. But the process will end without installing because the tests were not 100% successful. The failed tests are not significant in this case, and you can finish the install process with the command 'force install DBD::mysql'. This will override the test requirement, and install the software. -Bill -- William B. Birkett [EMAIL PROTECTED] Owner Precision Color, Inc. - http://www.pcolor.com/ 9200 General Drive, Plymouth, MI 48170 (USA) Phone: (734) 459-5640 FAX:(734) 459-4210 Cell: (734) 516-4790 Direct: (734) 414-3608
Re: CPAN can't write makefiles after perl 5.8.1 reinstall on 10.3.4
On 2004.7.15, at 06:43 AM, Brian Dimeler wrote: Hi, I was having trouble installing LWP on the version of Perl that came with our office iMac (running OS X 10.3.4) and therefore I reinstalled Perl as per the suggestion of CPAN, using the guide at http://developer.apple.com/internet/opensource/perl.html . my, oh, my. Would someone else take a look at that page and tell me whether they agree with me that it looks like some summer intern at Apple has kind of laid a little land mine in there, maybe thinking he was bringing the page up to date with Panther? ...
Re: Cannot load DBD::MySQL - Can't locate connnect.al
On Jul 15, 2004, at 8:15 AM, Bill Birkett wrote: 5. Now, you can use CPAN to compile and install 'DBD::mysql'. Type the command 'install DBD::mysql' as with DBI. The software will compile successfully (after first compiling some prerequisites), and pass most of its tests. But the process will end without installing because the tests were not 100% successful. The tests were not be 100% successful because this is incorrect. Why do people persist in posting misinformation about this? It ain't rocket science, and the correct recipe has been posted here a bazillion times. If you're using the CPAN shell, use the command 'look DBD::mysql' - this will download and unpack the module package, and open a command shell in the unpacked directory. Then execute the following: perl Makefile.PL \ --cflags='-I/usr/local/mysql/include -O3 -fno-omit-frame-pointer' \ --libs='-L/usr/local/mysql/lib -lmysqlclient -lz -lm' \ --testdb='test'\ --testuser='root'\ --testpassword='XX' Note that you must have set the root password according to the MySQL installation instructions. After the dust settles, you can proceed with the rest. Exit from the command shell (with 'exit' or ctrl-d) and complete the install in the CPAN shell: install DBD::mysql The tests should all pass. The failed tests are not significant in this case That is not always true. The failed tests *might* be a result of not being able to connect to the test database, and if that happens to be true then the failures are safe to ignore. But then, they might also indicate that the database did not start correctly, that the compiler is unable to find the necessary headers and/or library, or another problem. In these cases, the tests most definitely *are* meaningful, and forcing the CPAN shell to ignore them with 'force install' with accomplish nothing but installing a non-functional module. sherm--
Re: CPAN can't write makefiles after perl 5.8.1 reinstall on 10.3.4
On Jul 15, 2004, at 9:14 AM, Joel Rees wrote: Would someone else take a look at that page and tell me whether they agree with me that it looks like some summer intern at Apple has kind of laid a little land mine in there, maybe thinking he was bringing the page up to date with Panther? Absolutely. I wish Apple would take that page down - it was broken even for Jaguar. The latest Perl (5.8.4) comes with a readme.macosx file. Please, read and follow those instructions. Apple's instructions may be of interest to historians, but they have no relevance to the current Mac OS X. sherm--
Re: CPAN can't write makefiles after perl 5.8.1 reinstall on 10.3.4
(B Would someone else take a look at that page and tell me whether they (B agree with me that it looks like some summer intern at Apple has kind (B of laid a little land mine in there, maybe thinking he was bringing (B the page up to date with Panther? (B (B Absolutely. I wish Apple would take that page down - it was broken (B even for Jaguar. (B (BWhat I'm wondering about is this: (B (B--- (BA quick trip to Jaguar$B!G(Bs Terminal showed me that this version didn$B!G(Bt (Bmake it into the default install: (B (B [cpu:~] user% perl -v (B This is perl, v5.8.1-RC3 built for darwin-thread-multi-2level (B--- (B (BI'm supposed to believe that little exchange was on a default Jaguar (Binstall? (B (B The latest Perl (5.8.4) comes with a readme.macosx file. Please, read (B and follow those instructions. Apple's instructions may be of interest (B to historians, but they have no relevance to the current Mac OS X. (B (BI note the original was contributed. Maybe it's time to contribute a (Bnew one. I wonder if I kept any notes when I did the parallel install (Bof 5.8.4 on this Jaguar box. (B (B-- (BJoel Rees (B Opinions are like armpits. (B We all have two, and they all smell, (B but we really don't want the other guy to get rid of his.
Re: CPAN can't write makefiles after perl 5.8.1 reinstall on 10.3.4
On Jul 15, 2004, at 10:10 AM, Joel Rees wrote: I note the original was contributed. Maybe it's time to contribute a new one. I did. It's titled readme.macosx, and it's part of the standard Perl distribution now. ;-) sherm--
Re: CPAN can't write makefiles after perl 5.8.1 reinstall on 10.3.4
On Jul 15, 2004, at 10:10 AM, Joel Rees wrote: I'm supposed to believe that little exchange was on a default Jaguar install? Meh. Looks to me like the update is living up to the quality standard set by the original. Apple, just shoot that page like a lame horse. Put it out of our misery. sherm--
MIME-tools 5.411a on 10.2.8 vs 10.3.4
Hello all. I used to install MIME-tools 5.411a via the CPAN shell on MacOS X 10.2.8 (and 10.1.5) without any problems. Trying to do the same on MacOS X 10.3.4 ends with an error while doing 'make test'. The error can be seen in Ref.tlog: --- 1..50 [...] Trying ./testmsgs/russian.ref [./testmsgs/russian.msg] Default charset: KOI8-R** PARSE LOG FOR ./testmsgs/russian.ref [./testmsgs/russian.msg] ** debug:process_header ** debug:type = text, subtype = plain ** debug:process_singlepart... ** debug:taking shortcut ** debug:extract uuencode? undef ** debug:encoding? 7bit ** debug:effective type? text/plain ** debug:is this evil? 'Û²¦À.doc' ** debug:it's ok ** debug:planning to use 'Û²¦À.doc' ** debug:outputting body to disk file: testout/Ref_t/Û²¦À.doc 41: ./testmsgs/russian.ref 41: Problem: write-open testout/Ref_t/\F3\D0\C9\D3\CF\CB.doc: \ Invalid argument at \ /Users/pascal/Desktop/MIME-tools-5.411/blib/lib/MIME/Body.pm \ line 414, GEN80 line 4.\n 41: not ok 41 42: Did purge work? 42: Purgeable: testout/Ref_t/\F3\D0\C9\D3\CF\CB.doc 42: ok 42 [...] --- It seems something goes wrong while decoding the binary encoded Russian filename. I just can't see what it is... Has anyone seen this before? What can I do/try/test? BTW: same results for the 6.011 dev version. Thanks a lot in advance! Pascal
Re: CPAN can't write makefiles after perl 5.8.1 reinstall on 10.3.4
On 15 Jul 2004, at 06:43, Brian Dimeler wrote: I can't install --anything-- with CPAN. Any time it gets to the Writing makefile for whatever.. step I get a -- NOT OK, oddly enough I had the same problem with a just-out-of-the-box iBook trying to install Net::FTP with CPAN. I ended up cd-ing to the CPAN directory and doing a manual make there (make; make test; make install). Specs: OSX Mac OS X 10.3.4 (7H63) perl, v5.8.1-RC3 built for darwin-thread-multi-2level Robin
Re: MIME-tools 5.411a on 10.2.8 vs 10.3.4
On Jul 15, 2004, at 10:31 AM, Pascal Oberndoerfer wrote: I used to install MIME-tools 5.411a via the CPAN shell on MacOS X 10.2.8 (and 10.1.5) without any problems. Trying to do the same on MacOS X 10.3.4 ends with an error while doing 'make test'. The error can be seen in Ref.tlog: It looks like MIME::Tools is tripping over Perl 5.8's UTF8 support. Looking through MIME::Tools, it appears that it manually encodes UTF8 strings by inserting the necessary escapes into ordinary ASCII strings. This worked (and was necessary) with earlier Perls, because they didn't know about UTF8 - ASCII bytes were passed as-is to system calls that are UTF8-aware, and those system calls figured out the UTF8 encoding. Beginning with 5.8, Perl understands the difference between ASCII and UTF8. When passing an ASCII string to a system function it knows is UTF8-aware, it encodes the contents of the string as UTF8. UTF8 escape sequences found in the ASCII string aren't interpreted as such - they're escaped again, so that the result is a UTF8 representation of the text in the string, complete with backslashes and hex numbers. One fix would be to use 5.8's utf8::upgrade() function. That sets Perl's UTF8 flag for ASCII strings that have been manually encoded, so that it interprets the bytes in them as UTF8. A better fix might be to use 5.8's utf8::encode() function instead of manually encoding strings to begin with. sherm--
Re: MIME-tools 5.411a on 10.2.8 vs 10.3.4
Sherm Pendley at [EMAIL PROTECTED]: On Jul 15, 2004, at 10:31 AM, Pascal Oberndoerfer wrote: I used to install MIME-tools 5.411a via the CPAN shell on MacOS X 10.2.8 (and 10.1.5) without any problems. Trying to do the same on MacOS X 10.3.4 ends with an error while doing 'make test'. The error can be seen in Ref.tlog: It looks like MIME::Tools is tripping over Perl 5.8's UTF8 support. Looking through MIME::Tools, it appears that it manually encodes UTF8 strings by inserting the necessary escapes into ordinary ASCII strings. This worked (and was necessary) with earlier Perls, because they didn't know about UTF8 - ASCII bytes were passed as-is to system calls that are UTF8-aware, and those system calls figured out the UTF8 encoding. Beginning with 5.8, Perl understands the difference between ASCII and UTF8. When passing an ASCII string to a system function it knows is UTF8-aware, it encodes the contents of the string as UTF8. UTF8 escape sequences found in the ASCII string aren't interpreted as such - they're escaped again, so that the result is a UTF8 representation of the text in the string, complete with backslashes and hex numbers. One fix would be to use 5.8's utf8::upgrade() function. That sets Perl's UTF8 flag for ASCII strings that have been manually encoded, so that it interprets the bytes in them as UTF8. A better fix might be to use 5.8's utf8::encode() function instead of manually encoding strings to begin with. sherm-- Scanning through the results at http://testers.cpan.org/show/MIME-tools.html#MIME-tools-5.411a this seems to be related to 5.8.1 (RC1?). It does work with 5.8.0 (as supplied with 10.2.8). And the error doesn't seem to occur with 5.8.4 e.g. on Linux. Thanks again for the clarification! Pascal
Re: MIME-tools 5.411a on 10.2.8 vs 10.3.4
On Jul 15, 2004, at 11:58 AM, Pascal Oberndoerfer wrote: Scanning through the results at http://testers.cpan.org/show/MIME-tools.html#MIME-tools-5.411a this seems to be related to 5.8.1 (RC1?). It does work with 5.8.0 (as supplied with 10.2.8). And the error doesn't seem to occur with 5.8.4 e.g. on Linux. Jaguar 10.2.8 ships with 5.6.0. I get the same error with 5.8.4 on Panther - it might have something to do with Perl's interaction with HFS+. Perhaps there's a compile-time option I could use when building Perl that would avoid the problem. sherm--
Mason and undefined symbols error
Hello, I need some help troubleshooting an 'Undefined symbols' error. I'm trying to get Mason/mod_perl/Apache to install and work properly. Currently I am running Mac OS X 10.2.8. I first installed Perl v5.8.4. (I still have the Perl 5.6 installation that comes from Apple.) I installed Apache 1.3.31 and mod_perl 1.29, which installed sucessfully and seem to work fine. (I explicitly used perl 5.8 to run Makefile.PL) Next I installed HTML::Mason and dependancies using the CPAN module. When I started up the CPAN shell, I also explicitly used perl 5.8. I then added the following to my httpd.conf file: PerlModule HTML::Mason::ApacheHandler FilesMatch \.html$ SetHandler perl-script PerlSetVar MasonDataDir /usr/local/mason PerlSetVar MasonCompRoot /Library/WebServer/Documents PerlHandler HTML::Mason::ApacheHandler /FilesMatch Alas, now when I try to start Apache, I recieve the 'Undefined symbols' error (see below). I would appreciate any help that can be offered. Thanks Andrew error below : # andrewbr# apachectl start dyld: /usr/sbin/httpd Undefined symbols: _PL_curpad _PL_markstack_ptr _PL_op _PL_stack_base _PL_stack_sp _PL_sv_undef _PL_sv_yes _PL_tainting _Perl_croak _Perl_form _Perl_get_sv _Perl_getcwd_sv _Perl_mg_set _Perl_newXS _Perl_sv_2pv_flags _Perl_sv_2pv_nolen _Perl_sv_newmortal _Perl_sv_setpv _Perl_sv_setpvn _Perl_sv_setsv_flags _Perl_sv_taint /usr/sbin/apachectl: line 186: 9293 Trace/BPT trap $HTTPD /usr/sbin/apachectl start: httpd could not be started
Re: Mac::Glue and Address Book
Thanks, Chris - this will give me enough info to do what I need to do, I'm sure. Hopefully my Mac::AddressBookMerger won't be too far behind... my wife needs it to merge the addresses from our various address lists into one place. -Ken On Jul 14, 2004, at 3:54 PM, Chris Nandor wrote: Hope that helps, [...]
Re: Mason and undefined symbols error
Hello Andrew, I had similar problems when getting Perl 5.8.4 / Apache / mod_perl to work. It stems from the fact that OS X really is happier when you build a dynamic libperl (in fact, thats the way the shipped version of Perl on OS X is) So, the way I fixed this was to recompile Perl with -Duseshrlib and then I built mod_perl as a DSO. Since then its worked great. (Also, building a dynamic libperl fixed my DBD::mysql issues as well). -- Jeff On Jul 15, 2004, at 12:36 PM, Andrew Brosnan wrote: Hello, I need some help troubleshooting an 'Undefined symbols' error. I'm trying to get Mason/mod_perl/Apache to install and work properly. Currently I am running Mac OS X 10.2.8. I first installed Perl v5.8.4. (I still have the Perl 5.6 installation that comes from Apple.) I installed Apache 1.3.31 and mod_perl 1.29, which installed sucessfully and seem to work fine. (I explicitly used perl 5.8 to run Makefile.PL) Next I installed HTML::Mason and dependancies using the CPAN module. When I started up the CPAN shell, I also explicitly used perl 5.8. I then added the following to my httpd.conf file: PerlModule HTML::Mason::ApacheHandler FilesMatch \.html$ SetHandler perl-script PerlSetVar MasonDataDir /usr/local/mason PerlSetVar MasonCompRoot /Library/WebServer/Documents PerlHandler HTML::Mason::ApacheHandler /FilesMatch Alas, now when I try to start Apache, I recieve the 'Undefined symbols' error (see below). I would appreciate any help that can be offered. Thanks Andrew error below : # andrewbr# apachectl start dyld: /usr/sbin/httpd Undefined symbols: _PL_curpad _PL_markstack_ptr _PL_op _PL_stack_base _PL_stack_sp _PL_sv_undef _PL_sv_yes _PL_tainting _Perl_croak _Perl_form _Perl_get_sv _Perl_getcwd_sv _Perl_mg_set _Perl_newXS _Perl_sv_2pv_flags _Perl_sv_2pv_nolen _Perl_sv_newmortal _Perl_sv_setpv _Perl_sv_setpvn _Perl_sv_setsv_flags _Perl_sv_taint /usr/sbin/apachectl: line 186: 9293 Trace/BPT trap $HTTPD /usr/sbin/apachectl start: httpd could not be started
Re: Mason and undefined symbols error
Hello, Sorry to be a pest, but I'm rather confused by these 'undefined symbol' errors. Yes, I have two versions of Perl installed, but they are in different locations. Also, they have no common directories in their respective @INC (except '.'). I am further confused by posts in the archive and elsewhere. Some seem to say, 'Find the old offending libraries and remove them.' While others seem to say, 'Don't mess with Apple's version of Perl. Install a second version instead.' So which approach is correct? Is it safe to replace Apple's 5.6 version of Perl with 5.8 (FWIW, I'm still running 10.2) Thanks, Andrew On 7/15/04 at 12:36 PM, [EMAIL PROTECTED] (Andrew Brosnan) wrote: Hello, I need some help troubleshooting an 'Undefined symbols' error. I'm trying to get Mason/mod_perl/Apache to install and work properly. Currently I am running Mac OS X 10.2.8. I first installed Perl v5.8.4. (I still have the Perl 5.6 installation that comes from Apple.) I installed Apache 1.3.31 and mod_perl 1.29, which installed sucessfully and seem to work fine. (I explicitly used perl 5.8 to run Makefile.PL) Next I installed HTML::Mason and dependancies using the CPAN module. When I started up the CPAN shell, I also explicitly used perl 5.8. I then added the following to my httpd.conf file: PerlModule HTML::Mason::ApacheHandler FilesMatch \.html$ SetHandler perl-script PerlSetVar MasonDataDir /usr/local/mason PerlSetVar MasonCompRoot /Library/WebServer/Documents PerlHandler HTML::Mason::ApacheHandler /FilesMatch Alas, now when I try to start Apache, I recieve the 'Undefined symbols' error (see below). I would appreciate any help that can be offered. Thanks Andrew error below : # andrewbr# apachectl start dyld: /usr/sbin/httpd Undefined symbols: _PL_curpad _PL_markstack_ptr _PL_op _PL_stack_base _PL_stack_sp _PL_sv_undef _PL_sv_yes _PL_tainting _Perl_croak _Perl_form _Perl_get_sv _Perl_getcwd_sv _Perl_mg_set _Perl_newXS _Perl_sv_2pv_flags _Perl_sv_2pv_nolen _Perl_sv_newmortal _Perl_sv_setpv _Perl_sv_setpvn _Perl_sv_setsv_flags _Perl_sv_taint /usr/sbin/apachectl: line 186: 9293 Trace/BPT trap $HTTPD /usr/sbin/apachectl start: httpd could not be started
Re: Mason and undefined symbols error
On Jul 15, 2004, at 2:44 PM, Andrew Brosnan wrote: I am further confused by posts in the archive and elsewhere. Some seem to say, 'Find the old offending libraries and remove them.' While others seem to say, 'Don't mess with Apple's version of Perl. Install a second version instead.' So which approach is correct? The answers you read were correct within the context of working with ordinary Perl modules that have been compiled for an earlier version of Perl. But that is not the case here. You're not building an ordinary module - you're building mod_perl. Do Hyun Kim's answer in this case is appropriate - try building your Perl with a dynamic libperl instead of the default static libperl. (I've encountered similar problems building mod_perl on older versions of Solaris - it can be a finicky build.) Is it safe to replace Apple's 5.6 version of Perl with 5.8 (FWIW, I'm still running 10.2) Probably. It's definitely safe to leave Apple's version intact. Whether you'd prefer probably safe or definitely safe is up to you. What level of risk are you comfortable with taking? sherm--
Re: Mason and undefined symbols error
On 7/15/04 at 2:53 PM, [EMAIL PROTECTED] (Sherm Pendley) wrote: ... But that is not the case here. You're not building an ordinary module - you're building mod_perl. Do Hyun Kim's answer in this case is appropriate - try building your Perl with a dynamic libperl instead of the default static libperl. I'll try that next. I had opted not to build mod_perl as a DSO since the Mason book specifically recommends against it, and running Mason was the point of this now tiresome exercise :-) Further, since Apache and mod_perl work fine until I add the Mason related directives to httpd.conf, I assumed the culprit was not mod_perl. (I've encountered similar problems building mod_perl on older versions of Solaris - it can be a finicky build.) Yes, Voodoo is great fun ;-) Thanks, Andrew
Re: Mason and undefined symbols error
On Jul 15, 2004, at 3:15 PM, Andrew Brosnan wrote: I'll try that next. I had opted not to build mod_perl as a DSO since the Mason book specifically recommends against it That's a different question. You could try building Perl with a dynamic libperl, and still build mod_perl as a static Apache extension. That combination might work better than building both statically - I don't know, I haven't tried that particular combination on Mac OS X. The recipe varies. On the old Solaris machines I mentioned earlier, Apache would refuse to start if they both libperl and mod_perl were static, or both dynamic - one and only one of them had to be dynamic. The truly bizarre part was that it didn't matter which one. (That was one of the very few occasions where I gave up trying to figure out the logical answer, and simply accepted that the voodoo worked...) point of this now tiresome exercise :-) Further, since Apache and mod_perl work fine until I add the Mason related directives to httpd.conf, I assumed the culprit was not mod_perl. Have you tried any other directives that try to load an XS module? Yes, Voodoo is great fun ;-) I'm glad you think so, because the next step involves a bell, a book, a candle, and liberal applications of holy water. The demons in the machine must be exorcised! ;-) sherm--
Re: Mason and undefined symbols error
This might be a little out of our developed world mindset, but I have heard numerous missionaries report that people in their host countries will do the exorcism first off on all kinds of equipment, especially cars and trucks and generators and household appliances. The general conclusion is that it works well and it is lot cheaper then finding a mechanic or engineer. Could be they know things that some of us don't know. Joe. On Jul 15, 2004, at 2:41 PM, Sherm Pendley wrote: Yes, Voodoo is great fun ;-) I'm glad you think so, because the next step involves a bell, a book, a candle, and liberal applications of holy water. The demons in the machine must be exorcised! ;-) sherm--
Re: Mason and undefined symbols error
On Jul 15, 2004, at 2:52 PM, Ken Williams wrote: I know of no problems with DSO mod_perl Mason on OS X. You should be safe using it, assuming you can get it to work in the first place. The problems we referred to in the book were mostly on a couple flaky distributions of Linux. Actually, I think it has to do with how malloc is compiled into the Perl used by the mod_perl DSO. See: http://perl.apache.org/docs/1.0/guide/install.html#When_DSO_can_be_Used On Panther, I get: % /usr/bin/perl5.8.1 -V:usemymalloc usemymalloc='n'; So it's probably usable. Regards, David
Re: Mason and undefined symbols error
On Jul 15, 2004, at 3:01 PM, David Wheeler wrote: On Panther, I get: % /usr/bin/perl5.8.1 -V:usemymalloc usemymalloc='n'; So it's probably usable. Actually, to be more specific: % /usr/bin/perl5.8.1 -V:bincompat5005 -V:usemymalloc bincompat5005='UNKNOWN'; usemymalloc='n'; So it should work, provided that the mod_perl DSO that ships with Panther uses the same Perl library. Regards, David
