bmckenzie has asked for the wisdom of the Perl Monks concerning the following question:

Hi There,

So I had the MacPorts Perl working pretty well, but connection to the local mySQL database took too long, so I decided to try installing mod_perl2. This was a mistake, The installation failed ("perl5 must be +shared").

But enough changed (resulting from "sudo port upgrade perl5 +threads"?) to disable CGI::Carp fatalstobrowser, a feature of modperl2 I learned about after the fact. Now, in my development environment, I'd much prefer waiting for the db connect to not having my (many) errors appear in the browser.

I hope I don't need to uninstall MacPorts and start over. I just want my errors back in the browser :-)

Bruce

  • Comment on Help re-enabling CGI::Carp fatalstobrowser

Replies are listed 'Best First'.
Re: Help re-enabling CGI::Carp fatalstobrowser
by Corion (Patriarch) on Jan 31, 2012 at 14:06 UTC

    So, how does it fail?

    Note that CGI::Carp is distributed with CGI, so you should be able to reinstall it by reinstalling CGI.

      It fails "in requirement", but not because Carp isn't installed -- it was installed by MacPorts.

      The CGI::Carp documentation is clear about its incompatibility with mod_perl2. But I didn't read the CGI::Carp documentation until after CGI::Carp stopped working.

      So my situation is, mod_perl doesn't work because it wouldn't install. And CGI::Carp doesn't work (any more), presumably because something changed in the attempt to install mod_perl. This is on OS X Lion, BTW.

        The CGI::Carp documentation is clear about its incompatibility with mod_perl2.

        Actually it is not clear at all :)

        Overriding the program name in the use line use CGI::Carp 'name=progg'; doesn't work because its a global variable, that is all (see CGI::Carp in Apache::Registry)

        In 10 years I've never used that feature, but it could easily be fixed to work in a persistent shared interpreter like mod_perl