I am running Fedora Core 1

I want to study and practise using MySQL with an Apache server using Perl and DBI - hence
LAMP - Linux, Apache, MySQL, Perl.

Fedora Core 1 comes with MySQL 3.x and I wanted to upgrade to the newly stabilised MySQL 4.1 because I want foreign key restraints and subselect queries. (I'm interested in databases not fiddling about with all this configuration and installation).

I successfully removed the old MySQL and installed all the various RPMs available from the mysql website so now 4.1 is running with its control center and I can work directly with my favourite practice databases. Everything also works beautifully in Tomcat with JSP.

I upgraded Perl and now I think I'm running 5.8.1 (though I thought I was trying to install 5.8.5. The make, make install process is incredibly time-consuming and bewildering but at the end of the day, perl is working smoothly.

I managed to install the DBI module and the DBD MySQL driver from CPAN. So now, from a shell I can run perl programs which access MySQL successfully.

So, MySQL 4.1 is talking smoothly to Perl.

I used the same syntax to connect to the database and added the relevant bits of HTML to run it in Apache. These files run perfectly well on my other Linux boxes where I'm just using the packages supplied with the distribution (including MySQL 3.x) so the Perl, DBI HTML syntax is sound.

However, I constantly get errors in the error log along these lines:

install_driver(mysql) failed: Can't locate DBD/mysql.pm in @INC
(@INC contains:

then there follows a list of paths where Apache is expecting mysql.pm

I have just successfully compiled and installed the latest Apache from apache.org hoping that the compilation process would find the necessary bits of perl and figure out what to do but the basic error of not being able to find mysql.pm is exactly the same.

I'm not trying to use the mysql.pm and I didn't try to install it. I'm trying to use DBI with the DBD driver, so why is Apache looking for mysql.pm?

This is driving me crazy because all I want to do is a bit of bog-standard MySQL/Perl on one of the most popular webservers around. Why is it so fiendishly difficult?

Can anyone help me resolve this problem?

here's a wild guess. you say you upgraded mysql. sometimes an upgrade can go slighly off because of an out-of-date my.cnf from a previous installation. did you rename / remove your old /etc/my.cnf ? I wonder if some setting from the old my.cnf could cause this problem.

I've been experimenting with the build configuration and have finally got Apache running and successfully connecting to MySQL version 4.1 with Perl and DBI.

The crucial setting is the architecture-dependent installation directory. The key point is install Apache using default settings, but configure your new Perl installation to ensure that any architecture-dependent files are placed in a directory that Apache expects.

I found that, if I attempted to configure Apache in any way apart from the defaults, I ran into difficulties. The only thing I needed to set was the installation directory.

So, installing Apache from source involved the 4 commands set out in the installation instructions:

# ./configure --prefix=/usr/local/apache2
# make
# make install
#/usr/local/apache2/bin/apachectl start

Now, after installing DBI and DBD from source, I tried to run my test DB connection page and got the usual error about being unable to locate the MySQL driver, but this time I paid more attention to which directories Apache was searching to find a suitable driver for MySQL. When I compared them to the directories where Perl 5.8.5 had installed itself, I realised the default Perl installation had stored various bits and pieces in places that Apache wasn't expecting. After reading through installation instructions for Apache and Perl more carefully, I found there is a setting for choosing a location for architecture-dependent files. Perl 5.8.5, by default, creates some directories with names starting with i686 on Fedora Linux but Apache on this distribution is looking for directories based on the name -i386.

I removed my new Perl 5.8.5 installation and deleted everything I could think of related to it, then re-installed, this time choosing an interactive configuration session.

The sequence of commands is:

# rm -f config.sh Policy.sh
# Configure
# make
# make test
# make install

(In order to enter interactive Configuration mode, you don't type -de after Configure )

You have to stay awake during this because it asks some really obscure questions and often says "if you don't understand this just press return". So, when you get to the questions about the location of the installation directories, slow down, take your time and when they ask about the architecture-dependent installation directory, type:

-i386.

This time, perl installed itself in a directory called /usr/lib/perl5 and created some sub-directories called -i386-linux-thread-multi instead of -i686-linux-thread-multi and hey presto after re-installing DBI and the MySQL DBD module, Apache was able to find the driver it needs to run my test SELECT query.

I've seen many posts in many forums over the last week with a very similar error running Apache with Perl or Python MySQL or PosgreSQL etc so it could be that the solution is to re-build the relevant scripting language (Perl or whatever) but ensure that it's configured to put architecture-dependent files in a location that Apache is expecting.


Hope this helps someone. It's taken me about 10 days of rather late nights to get this to work.