How can I install Perl's DBI on Mac OS X so Apache can find it? - perl

I'm trying to setup a Perl development environment on my Mac laptop and have been having a really hard time getting it working. I thought I had everything configured correctly but when I try to run a sample script it is reporting errors with the DBI module and can't access the DB.
Here is what is reported in the Apache error logs:
[Fri Apr 30 23:11:33 2010] [error] [client 127.0.0.1] Can't locate DBI.pm in #INC (#INC contains: /Library/Perl/Updates/5.10.0/darwin-thread-multi-2level /Library/Perl/Updates/5.10.0 /System/Library/Perl/5.10.0/darwin-thread-multi-2level /System/Library/Perl/5.10.0 /Library/Perl/5.10.0/darwin-thread-multi-2level /Library/Perl/5.10.0 /Network/Library/Perl/5.10.0/darwin-thread-multi-2level /Network/Library/Perl/5.10.0 /Network/Library/Perl /System/Library/Perl/Extras/5.10.0/darwin-thread-multi-2level /System/Library/Perl/Extras/5.10.0 .) at main.pm line 5.
I downloaded and installed both modules manually to work with MAMP using the following commands as specified in this forum post:
For DBI
1. cd /Library/Perl/DBI-1.611
2. sudo Perl Makefile.PL
3. sudo make
4. sudo make install
For DBD
1. cd /Library/Perl/DBD-mysql-4.014
2. sudo Perl Makefile.PL --mysql_config=/Applications/MAMP/Library/bin/mysql_config
3. sudo make
4. sudo make install
What I noticed while running the above commands is that the files seems to be getting installed in the '/opt/local/lib/perl5/site_perl/5.8.9/darwin-2level/' directory which doesn't seem to be one of the search directories that Apache mentions in the error at the beginning of this post. Here is what I'm seeing during the install:
$ sudo make install
Files found in blib/arch: installing files in blib/lib into architecture dependent library tree
Installing /opt/local/lib/perl5/site_perl/5.8.9/darwin-2level/auto/DBI/DBI.bundle
Installing /opt/local/lib/perl5/site_perl/5.8.9/darwin-2level/auto/DBI/dbipport.h
Installing /opt/local/lib/perl5/site_perl/5.8.9/darwin-2level/auto/DBI/DBIXS.h
Installing /opt/local/lib/perl5/site_perl/5.8.9/darwin-2level/auto/DBI/dbixs_rev.h
Installing /opt/local/lib/perl5/site_perl/5.8.9/darwin-2level/auto/DBI/Driver.xst
Installing /opt/local/lib/perl5/site_perl/5.8.9/darwin-2level/auto/DBI/Driver_xst.h
Installing /opt/local/lib/perl5/site_perl/5.8.9/darwin-2level/DBI.pm
Installing /opt/local/lib/perl5/site_perl/5.8.9/darwin-2level/TASKS.pod
Installing /opt/local/lib/perl5/site_perl/5.8.9/darwin-2level/DBD/DBM.pm
Installing /opt/local/lib/perl5/site_perl/5.8.9/darwin-2level/DBD/File.pm
Installing /opt/local/lib/perl5/site_perl/5.8.9/darwin-2level/DBD/Gofer.pm
Installing /opt/local/lib/perl5/site_perl/5.8.9/darwin-2level/DBI/Changes.pm
Installing /opt/local/lib/perl5/site_perl/5.8.9/darwin-2level/DBI/DBD.pm
Installing /opt/local/lib/perl5/site_perl/5.8.9/darwin-2level/DBI/Profile.pm
Installing /opt/local/lib/perl5/site_perl/5.8.9/darwin-2level/DBI/ProxyServer.pm
Installing /opt/local/lib/perl5/site_perl/5.8.9/darwin-2level/DBI/PurePerl.pm
Installing /opt/local/share/man/man3/DBD::DBM.3pm
Installing /opt/local/share/man/man3/DBD::File.3pm
Installing /opt/local/share/man/man3/DBD::Gofer.3pm
Installing /opt/local/share/man/man3/DBI.3pm
Installing /opt/local/share/man/man3/DBI::DBD.3pm
Installing /opt/local/share/man/man3/DBI::Profile.3pm
Installing /opt/local/share/man/man3/DBI::ProxyServer.3pm
Installing /opt/local/share/man/man3/DBI::PurePerl.3pm
Installing /opt/local/share/man/man3/TASKS.3pm
Installing /opt/local/bin/dbiprof
Installing /opt/local/bin/dbiproxy
Writing /opt/local/lib/perl5/site_perl/5.8.9/darwin-2level/auto/DBI/.packlist
Appending installation info to /opt/local/lib/perl5/5.8.9/darwin-2level/perllocal.pod
My question is, what am I doing wrong and how can I either 1) Get Apache to look in the right directory where the DBD & DBI modules are installed or 2) Update the way I'm installing the module to install them into one of the search directories. I honestly don't know what option makes more sense and could use guidance on that as well.
As you can probably tell I'm pretty lost at the moment. Please help!!! Thanks in advance.

It looks like you've already installed another Perl via macports (/opt/local is where all macports installations go), and /opt/local/bin is earlier in your $PATH than the system Perl in /usr/bin. That's fine, if you are happy running Perl 5.8.9 rather than Perl 5.10.0 (hint: if you aren't sure of the differences, then the differences don't matter).
It's usually advised to not make extra installations to the system Perl. Apple may upgrade components through regular system updates, which could interfere with any modifications you have made, and if you make a mistake with an installation, it's difficult to remedy it without doing a full system reinstallation or having some serious understanding of the operating system guts. So, since you've already got another Perl installation ready, I would strongly encourage you to stick with that one.
However, you probably shouldn't be manually installing libraries if there is already a distribution available on macports. I used port search dbi and port search dbd to find them: the distributions are named p5-dbi and p5-dbd-mysql. You can install those like any other macports module: with sudo port install <distroname>. (You may need to install mod_perl itself, too.)
After that, you simply need to tell Apache/mod_perl to use that Perl installation rather than the system perl. I've never done that, so I can't advise on the best way to do it. However, quick searches on http://superuser.com suggest that the macports version of apache will run by default (via the same $PATH ordering), so I'd just Try It And See :).

Great answer, Ether. Having done this far too many times to count, I can give you a few pieces of advice:
Note: I am apparently limited to a single link in the post, so I had to remove all of my annotations. Thankfully, there is Delicious where I've stored them all with a stackoverflowmacports tag. Any place below where I removed a link to fit under Stack Overflow's ridiculous anti-spam measure, I've marked it with (*).
If having a reliably-working development environment at all times is important to you, rely on as LITTLE Mac OS X bundled software as possible. I love Apple but they have absolutely no qualms about breaking custom setups of their software as often as possible.
If #1 sounds like what you need to do, Macports is an EXCELLENT choice. I used to use Fink but they got left in the dust ages ago in terms of ease of use and spectrum of available software. The easiest route to installing macports is via the binary package install method (*)
As Ether mentions, when you have everything set up correctly, the Macports-provided MySQL, PHP and Apache all work together well without the system-installed analogs interfering. Most of that has to do with your PATH setting but all of those details are handled by the package installers post-flight script (*)
Once you're on the Macports train, it should become the very first place you look for any software. port search and port info are constant companions. They've got 6863 ports (*) currently which covers MOST of your bases.
When you do need to go outside of the Macports realm to find something, install it in /usr/local. That part of the file system hierarchy is yours to play with. Don't be lulled into a false sense of security and think that because Macports doesn't have what you're installing, it's okay to put it in /opt/local because invariably that software will install some dependency that will ALSO be a dependency for some piece of Macports software down the line and Macports will not allow a port to be installed if any one of its files would overwrite an existing file not managed by Macports (unless you force it which is always bad manners)
If you do any work with Perl and you use Macports' version, you will absolutely find yourself in a situation Macports doesn't have the one CPAN module you're looking for. (And, really, given that there are two and a half billion CPAN modules, who can blame them?). This will happen often enough that you will most likely tire of the manual installation method (*) (perl Makefile.PL; make; make test; sudo make install; cha; cha; cha) and long for the ease of use you've grown accustomed to with Macports.
If so, you can absolutely use the cpan (*) utility, CPANPLUS (*) or cpanminus (*) for all of your installing needs. Just make sure to make the necessary adjustments in the configuration of your tool of choice to instruct it to install your modules into /usr/local/lib/perl5, ignoring /opt/local/bin/perl's insistence that modules go into /opt/local/lib/perl5. You can set the PERL5LIB environment variable in your shell's init scripts to additionally look in /usr/local/lib/perl5 for modules. Just grab the #INC output from perl -V and tack it on the end...
And finally... Leveraging the system's daily init scripts or third-party software like Anacron (*) or MacPorts Notifier (*) (both available through MacPorts), make sure to update your software frequently. You don't have Mother Apple protecting you with Software Updates for the Macports installed software which have just as many bugs and security exploits as the very same software Apple bundles.
By updating frequently, you'll stay ahead of the baddies and by automating it, the upgrades will actually happen and you won't end up as I have in the past with a full weekend blown because you had a mountain of outdated ports to upgrade. Note: Macports stages its updates and if it fails at any point, your current version continues to work. Apple could learn a thing or two from them, I tell ya...
So, that's all I can think of a the moment. Hopefully the lessons above will get you going quickly and save all of the time, effort and stress I've experienced in past years in learning it. I would argue it's still far better than the alternative: Hating Apple because they break all of your nice things... :-)

I had a similar problem with Apache using the wrong Perl. I fixed it by appending the following lines to my httpd.conf file:
SetEnv PATH [colon-separated list of directories]
SetEnv PERL5LIB [colon-sep'd list of directories]
In my case, it looked like this:
SetEnv PATH /opt/local/bin:/opt/local/sbin:/usr/local/bin:/usr/local/mysql/bin:$PATH
SetEnv PERL5LIB /opt/local/lib:/usr/local/lib

Related

Variant Effect Predictor | DBD mysql failing to setup

I trying to get set up with Variant Effect Predictor (VEP) on the command line. I'm following the setup tutorial but I'm encountering some errors around dependencies. I'm also quite new to the command line so if anyone is able to break down the solution too then I'd be very grateful. Thanks!
Tutorial: https://www.ensembl.org/info/docs/tools/vep/script/vep_tutorial.html
VEP requirements: http://www.ensembl.org/info/docs/tools/vep/script/vep_download.html#requirements
I also have Perl v5.32.1.
What I've done:
I installed dependencies (listed in the requirements page) with the following commands:
- sudo -s cpanm DBI
- sudo -s cpanm Archive::Zip
- sudo -s cpanm DBD::mysql
For DBD:mysql, I got the follwoing message:
--> Working on DBD::mysql
Fetching http://www.cpan.org/authors/id/D/DV/DVEEDEN/DBD-mysql-4.050.tar.gz ... OK
Configuring DBD-mysql-4.050 ... N/A
! Configure failed for DBD-mysql-4.050. See /root/.cpanm/work/1626111140.5937/build.log for details.
Trying it out anyway, I ran perl INSTALL.pl (from the tutorial page) and got the message below. I would like VEP to run in online mode too if possible.
`WARNING: DBD::mysql module not found. VEP can only run in offline (--offline) mode without DBD::mysql installed
http://www.ensembl.org/info/docs/tools/vep/script/vep_download.html#requirements
Hello! This installer is configured to install v104 of the Ensembl API for use by the VEP.
It will not affect any existing installations of the Ensembl API that you may have.
It will also download and install cache files from Ensembl's FTP server.
Checking for installed versions of the Ensembl API...done
Setting up directories
Destination directory ./Bio already exists.
Do you want to overwrite it (if updating VEP this is probably OK) (y/n)? y
- fetching BioPerl
- unpacking ./Bio/tmp/release-1-6-924.zip
ERROR: Unable to unpack file ./Bio/tmp/release-1-6-924.zip without Archive::Extract or tar/unzip/gzip`
You show us this error:
Configure failed for DBD-mysql-4.050. See /root/.cpanm/work/1626111140.5937/build.log for details.
So looking in there will give you more clues about what the problems are. Without that, we can only guess.
But we can make educated guesses. The DBD::mysql distribution comes with a file called DBD::mysql::INSTALL which will talk you through some of the problems you'll find while installing this module.
It's important to note that DBD::mysql is a wrapper around MySQL's client libraries. They are written in C, so you'll need a C compiler installed in order to build DBD::mysql. You'll also need the client libraries and the development versions of the client libraries (for the C header files that you'll need to compile the module). On Ubuntu, those packages are called "libmysqlclient" and "libmysqlclient-dev". If you don't have a C compiler, then you'll want to install "gcc" too.
But this is all getting a bit complicated. There's another, simpler, approach. If you're using the system version of Perl (the version that was installed as part of the operating system and probably lives in /usr/bin/perl) then I'd recommend using the pre-build Ubuntu version of the package, which you can install by running:
$ sudo apt-get install libdbd-mysql-perl
Installing that version uses the OS's own package manager, and the package manager knows which other packages are needed in order for it to work - so it will install those as well.
People will probably complain that you're better off installing the modules from CPAN as it gives you more flexibility and allows you to use more up-to-date packages than the versions from your OS repos. And they're right. But, honestly, if you're a non-Perl programmer who just wants to get an application up and running, this is by far the simplest approach.
(But, as I said above, this is all guesswork as you haven't shared the most important errors with us.)

How to get p5-Switch on ubuntu 12.10

I was using ubuntu 12.04 until 12.10 was released. I used ubuntu for software development and after installing 12.10, i noticed that the perl version (5.14) shipped with 12.10 does not include the Switch.pm module needed while building WebKiT-GTK.
Looking around on the internet i found few suggestions indicating that i should install something call p5-switch from something called ports. I have looked around and was not able to get this done. I am not a perl guy and have no idea where i can get this package.
Can someone please help me as to
1. Where to download the package for ubuntu 12.10
2. In case it is not a .deb, How do i install it.
OR
1. At least be able to downgrade the perl installation to something lower than 5.14
Thanks and Regards
~Sameer
sudo apt-get install libswitch-perl
will install it for you.
"ports" is a *BSD packaging system of sorts, not what you should be looking for.
You can find what package has a particular perl module by going to packages.ubuntu.com, entering Module/Name.pm (in this case, Switch.pm) in the "Search the contents of packages" form and checking "packages that contain files whose names end with the keyword" and selecting the desired distribution, then making sure you ignore false hits like CGI/Switch.pm in the results. Debian has the identical search for its packages at packages.debian.org.
(Note that Switch.pm has serious limitations, was never really intended to be used in production, and should certainly not be used in new code.)
Do make sure you've checked properly that there isn't the Switch module available via apt. If it is available, that's the one you want.
No, then you've two options the longer, correct way and a shorter way that's not quite as clean.
1. Longer
Install cpanm and perlbrew with apt. The perlbrew tool lets you install a complete version of Perl from scratch in a separate directory. Set up a user for your webkit building, run perlbrew as that user, install your perl. Then, use cpanm to install required modules and you are done. A bit of googling will get you step-by-step examples of how to use these tools. If anything goes badly wrong, you can just delete all the files in that user's home directory and start again - all you waste is a little time.
The reason experienced Perl people prefer this is that it keeps the perl you want for webkit-gtk separate from your system perl that ubuntu's packages will expect to be unchanged from the one they ship.
2. Shorter
Install cpanm with apt. As root, run "cpanm Switch" and it will install the Switch.pm package and any dependencies. It will also upgrade any already installed packages it thinks it needs to. This last step is why this option isn't ideal. In the (rare) case when the update isn't compatible with something else on your system uninstalling is fiddly.

How can I restore my Perl environment and modules to a known state on Mac OS X? [closed]

Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
I am an old time Perl hacker but I have basically given up on my Mac because I usually can't install anything with cpan.
Something in the dependency list usually fails with meaningless (to me) errors. My Mac is new but has a long history copied over during upgrades from previous Macs for over 10 years.
Over the years I have tried to use fink, MacPorts and homebrew and I suspect by this time I have many incompatibilities.
Before I post my latest problem what I would really like to do is start clean with Perl as if I had a clean OSX-lion install. Is there any way to do this without wiping my disk and installing OSX from scratch?
None of the projects you mentioned installs into system directories. So, removing them from your current user environment should be as trivial as taking them out of your path, and removing references to them from your startup files (e.g., .bashrc, or if you added them to your "login items" etc).
After that, you'd be left with what the OS gives you. LEAVE THAT ALONE. Install perlbrew (so you can install multiple perls and switch among them without disturbing the rest of the system) and cpanm (cause it's more funner ;-) and take it from there.
Make sure to read the documentation for everything you use so you understand what they do and how they do it.
PS: If you did force any of fink, ports, or homebrew trample on system directories for some reason, you did it wrong. If I were you, I would choose to install from scratch in such a case (but make sure to back up your documents first). I personally think even /usr/local as homebrew developers advocate is not a good idea, but if you did that, at least they give you an uninstall script.
OS X and Perl = pain a bit, when want many modules.
Problems:
macports - default 5.12 optional 5.14. Unfortunately many macports has wrong dependencies, asking exactly 5.12 and when you have 5.14 running into problems Your default perl will be 5.14 and some packages will install and use 5.12 :(.
perlbrew - very good and easy but here is a drawback. When you want install some packages with macports and what are depend on macport's perl - it's get installed. So you will get one macport's perl (what will works with installed package and perlbrew perl). And what is worse, your e.g. 5.14 perlbrew will not play correctly with macports (default 5.12). E.g. p5-GD, ImageMagick and many many others.
homebrew - IMO, horrible. Stopped reading the doc when reach a section recommending rm -rf /usr/local. (of course, with all data, e.g. mysql). Maybe now it is better.
fink, same problems as macports.
My solution:
simple using macports version for real development and perlbrew only for testing (but not with dependent binaries, like GD and so on). When want "perlbrew" sourcing its shell-start-files, otherwise not and using macports.
Another source of pain is - trying install macports version of perl modules first (because of consistency and dependency) and only when macports version is not exists, or need the newest cpan version - installing it with cpanm. CPAN version Extutils::Makemaker does not like macports version - and recompiling it all times when installing modules with cpanm.
Real pain. Macports badly need a new perl - maintenaier, who will clean up wrong dependencies and make the macports version of cpanm what will install cpan version of modules correctly as macport packages. Something has FreeBSD has years ago - cpan modules comes into BSDPAN bundles what are manageable with pkg_* commands.
So the result: I'm currently don't known any easy OS X perl usage. immediately when you want use some perl-dependent software you will must compile them itself (and sometimes they will not compile - so you need the patched version for OSX, so start uses macports or homebrew and ... pain.. ;(
As Sinan already told - any of those installations does not interfere with your system perl, but you probably started using cpan first with system perl and installed some modules into /Library..
IMO, you can live with it. Simply install macports and start using it. But if you want some perl-repair-installation - probably the better place to ask is at: https://apple.stackexchange.com/ .

How do I install Devel::Cover on ActivePerl 5.8.7?

cpan fails with this weird error as follows
Error: Unable to locate installed Perl libraries or Perl source code.
It is recommended that you install perl in a standard location before
building extensions. Some precompiled versions of perl do not contain
these header files, so you cannot build extensions. In such a case,
please build and install your perl from a fresh perl distribution. It
usually solves this kind of problem.
(You get this message, because MakeMaker could not find "D:\fbl_esc_bcd_tb\tools\perl\lib\CORE\perl.h")
Running make test
Make had some problems, maybe interrupted? Won't test
Running make install
Make had some problems, maybe interrupted? Won't install
Problem is I can't install new active perl versions in this environment and the tool I want to coverage on does not run outside this environment.
Short answer: The ActiveState PPM repository has a precompiled version of Devel::Cover you should be able to install.
Long answer: That's not a normal message from MakeMaker so I'm willing to guess its an ActiveState addition, but its probably true. The problem is exactly what the error message says; your distribution is missing some important files, specifically the C header files for Perl, so it cannot compile C code necessary for modules like Devel::Cover. This is often the result of an overzealous sysadmin or packager looking to save a few dozen K of disk space. You could probably take the header files from the 5.8.7 source, copy them into the CORE directory and it will probably work. It won't make anything worse.
I agree with Evan that, assuming this is a Windows machine, you should switch to Strawberry Perl which plays much better with the rest of the Perl community than ActivePerl.
Otherwise, ActiveState is a commercial company and they have paid Perl support. Give them a ring.
Active Perl does not use CPAN. If you want to use CPAN use Strawberry Perl. Active Perl uses binary distribution through its ppm system. There are a few third party repos for it if the official one doesn't have Devel::Cover -- though the official probably has Devel::Cover.
Most people these days are moving to Strawberry and away from AS. In my opinion, it is far more stable and CPAN-friendly, and surely less proprietary. Also, expect to be able to get stable versions of most everything - AS has been known to lag years in many occasions in the official repos. strawberry also comes with its own compiler and build environment so you can even get ::XS versions working with ease.

How do I use a vendor Apache with a self-compiled Perl and mod_perl?

I want to use Apple's or RedHat's built-in Apache but I want to use Perl 5.10 and mod_perl. What's the least intrusive way to accomplish this? I want the advantage of free security patching for the vendor's Apache, dav, php, etc., but I care a lot about which version of Perl I use and what's in my #INC path. I don't mind compiling my own mod_perl.
Build your version of Perl 5.10 following any special instructions from the mod_perl documentation. Tell Perl configurator to install in some non-standard place, like /usr/local/perl/5.10.0
Use the instructions to build a shared library (or dynamic, or .so) mod_perl against your distribution's Apache, but make sure you run the Makefile.PL using your version of perl:
/usr/local/perl/5.10.0/bin/perl Makefile.PL APXS=/usr/bin/apxs
Install and configure mod_perl like normal.
It may be helpful, after step one, to change your path so you don't accidentially get confused about which version of Perl you're using:
export PATH=/usr/local/perl/5.10.0/bin:$PATH
You'll want to look into mod_so
I've done this before. It wasn't pretty, but it worked, especially since vendor perl's are usually 2-3 years old.
I started with making my own perl RPM that installed perl into a different location, like /opt/. This was pretty straight forward. I mostly started with this because I didn't want the system utilities that used perl to break when I upgraded/installed new modules. I had to modify all my scripts to specify #!/opt/bin/perl at the top and sometimes I even played with the path to make sure my perl came first.
Next, I grabbed a mod_perl source RPM and modified it to use my /opt/bin/perl instead of /usr/bin/perl. I don't have access to the changes I made, since it was at a different gig. It took me a bit of playing around to get it.
It did work, but I'm not an RPM wizard, so dependency checking didn't work out so well. For example, I could uninstall my custom RPM and break everything. It wasn't a big deal for me, so I moved on.
I was also mixing RPM's with CPAN installs of modules (did I mention we built our own custom CPAN mirror with our own code?). This was a bit fragile too. Again, I didn't have the resources (ie, time) to figure out how to bend cpan2rpm to use my perl and not cause RPM conflicts.
If I had it all to do again, I would make a custom 5.10 perl RPM and just replace the system perl. Then I would use cpan2rpm to create the RPM packages I needed for my software and compile my own mod_perl RPM.