 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Mac Forum / Programming / Perl / July 2004Mason 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 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 > Hello, > [quoted text clipped - 59 lines] > /usr/sbin/apachectl: line 186: 9293 Trace/BPT trap $HTTPD > /usr/sbin/apachectl start: httpd could not be started > > On Jul 15, 2004, at 12:36 PM, Andrew Brosnan wrote: > > [quoted text clipped - 4 lines] > > > > ... > ... > So, the way I fixed this was to recompile Perl with -Duseshrlib and > then I built [quoted text clipped - 5 lines] > > -- Jeff Thanks Jeff, Sherm & others, that did the trick. For the record, part of the problem was also due to libapreq, and this article: http://www.macdevcenter.com/pub/a/mac/2003/02/07/libapreq_update.html by David was also helpful getting that straightened out. Thanks again. Andrew 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 > Hello, > [quoted text clipped - 59 lines] > /usr/sbin/apachectl: line 186: 9293 Trace/BPT trap $HTTPD > /usr/sbin/apachectl start: httpd could not be started > I am further confused by posts in the archive and elsewhere. Some seem > to say, 'Find the old offending libraries and remove them.' While [quoted text clipped - 3 lines] > > 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-- > ... > > 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 > 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-- 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. >> Yes, Voodoo is great fun ;-) > [quoted text clipped - 3 lines] > > sherm-- > This might be a little out of our developed world mindset, but I have > heard numerous missionaries report that people in their host countries [quoted text clipped - 4 lines] > > Could be they know things that some of us don't know. No! No! No! Hardware requires *blood* sacrifices. Software required applied daemonology. (Or percussive maintenance.) > Joe. > [quoted text clipped - 5 lines] >> >> sherm-- >> ... >> [quoted text clipped - 8 lines] > the > point of this now tiresome exercise :-) 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. -Ken > 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 > 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 |
Reply to this Message |
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2009 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.