LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Linux - Newbie (https://www.linuxquestions.org/questions/linux-newbie-8/)
-   -   mysql + Perl (DBI) install problem (https://www.linuxquestions.org/questions/linux-newbie-8/mysql-perl-dbi-install-problem-508665/)

tekmann33 12-08-2006 03:38 PM
mysql + Perl (DBI) install problem
 
I am attempting to install and integrate mysql, PHP, and Apache using SAMS Teach Yourself book "PHP, MySQL, and Apache" by Julie C. Meloni as a guide.

The book suggests installing first Mysql, then Apache, then PHP.

I am having trouble installing MySQL because of a dependency with the Perl(DBI) module even though I already have it installed.

Here is my install process:

(I am running this on a Dell Optiplex GX260, Red Hat 9 machine)

1. I downloaded a client and server rpm of MySQL from mysql.com. When attempting to install it I received the following message:


[root@BriansRH src]# rpm -i MySQL-client-5.0.27-0.glibc23.i386.rpm MySQL-server-5.0.27-0.glibc23.i386.rpm
warning: MySQL-client-5.0.27-0.glibc23.i386.rpm: V3 DSA signature: NOKEY, key ID 5072e1f5
error: Failed dependencies:
perl(DBI) is needed by MySQL-client-5.0.27-0.glibc23
perl(DBI) is needed by MySQL-server-5.0.27-0.glibc23

2. So...I then acquired the Perl DBI bundle DBI-1.53.tar.gz from CPAN and unzipped it and untarred it.

3. As per the README file in the DBI directory, I executed the following commands.

perl Makefile.PL
make
make test
make install (if the tests look okay)

Everything looked good after each of these commands. These are the last few lines from the make test command. To me it looks like everything went okay with the DBI installation, meaning that there wasn't any error messages:

dbi:ExampleP:: testing 5 sets of 20 connections:
Connecting... 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
Disconnecting...
Connecting... 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
Disconnecting...
Connecting... 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
Disconnecting...
Connecting... 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
Disconnecting...
Connecting... 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
Disconnecting...
Made 100 connections in 0 wallclock secs ( 0.03 usr + 0.00 sys = 0.03 CPU)

Testing handle creation speed...
12500 NullP sth/s perl 5.008 i386-linux-thread-multi (gcc 3.2.2 -O2 -march=i386 -mcpu=i686 -g)

test.pl done



4. I then tried to install the mysql rpm's again and got this:

warning: MySQL-server-5.0.27-0.glibc23.i386.rpm: V3 DSA signature: NOKEY, key ID 5072e1f5
error: Failed dependencies:
perl(DBI) is needed by MySQL-server-5.0.27-0.glibc23
perl(DBI) is needed by MySQL-client-5.0.27-0.glibc23

I am not sure what I am doing incorrectly. I have not tried to install the mysql DBD module yet, but according to the README file, I do not need it to install perl(DBI).

I have researched this issue for a couple of days and I am no closer to figuring it out.

Any help would be appreciated.

144419855310001 12-08-2006 06:06 PM
I think this is because of the different methods you are using to install perl(DBI) and MySQL.

"RPM" is a "smart" package manager, in that when you install an rpm file, it updates the database on your distro so that your system "knows" that you have installed an rpm.

Thus if you install e.g. "a.rpm", afterwards when you come to install "b.rpm", which is say dependent on "a.rpm", everything will install ok. This is because the database has been updated to say that "a.rpm" has been installed, and so "b.rpm" installation can go ahead.

However, the problem is that when you manually install something from a tarball [as you did with perl(DBI)], the database is not updated, and so when you come to install "b.rpm", even though you have installed "a" from source, as you didn't use an rpm, RPM package manager doesn't know about it, so won't let you install "b.rpm".


Of course there is nothing wrong with using tarballs; some prefer it because it is more flexible, and you can optomise the compilation for maximum performance on your machine. However, 9 times out of 10, its usually much easier to use an rpm, if there is one for whatever it is you're trying to install.

The dependency part of RPM, which won't let you install programs until you have met the dependencies, is a feature! Instead of sitting there bewildered when your installation from source fails for some unknown reason because you're missing a dependency, when you install from rpm, it tells you exactly what prerequisite programs you need first.





So, what to do about it:
A) you can find the right rpm of perl(DBI) and do it that way
B) install both of perl(DBI) and MySQL from tarball/source (a lot of hassle: not recommended)
C) install the MySQL rpm with the option --nodeps, e.g.:
rpm -ivh --nodeps MySQL-client-5.0.27-0.glibc23.i386.rpm

...This tells RPM package manager to ignore the fact that it cannot find perl(DBI) in the database, because you know you've installed it from source.

A) is generally best practice, and will save headaches in the long run, but C) will probably work at the moment. Using C) can be risky if you're not careful about what it is you're doing.

Does that make sense?

tekmann33 12-09-2006 08:32 AM
rpm + tarball
 
Yes, that makes perfect sense. It seems odvious now that I think about it.

This particular installation that I have is at work. I will try finding a Perl(DBI) rpm and install it Monday morning.

Thanks for the advice.

tekmann33 12-11-2006 01:45 PM
Quote:
Originally Posted by 144419855310001
I think this is because of the different methods you are using to install perl(DBI) and MySQL.

"RPM" is a "smart" package manager, in that when you install an rpm file, it updates the database on your distro so that your system "knows" that you have installed an rpm.

Thus if you install e.g. "a.rpm", afterwards when you come to install "b.rpm", which is say dependent on "a.rpm", everything will install ok. This is because the database has been updated to say that "a.rpm" has been installed, and so "b.rpm" installation can go ahead.

However, the problem is that when you manually install something from a tarball [as you did with perl(DBI)], the database is not updated, and so when you come to install "b.rpm", even though you have installed "a" from source, as you didn't use an rpm, RPM package manager doesn't know about it, so won't let you install "b.rpm".


Of course there is nothing wrong with using tarballs; some prefer it because it is more flexible, and you can optomise the compilation for maximum performance on your machine. However, 9 times out of 10, its usually much easier to use an rpm, if there is one for whatever it is you're trying to install.

The dependency part of RPM, which won't let you install programs until you have met the dependencies, is a feature! Instead of sitting there bewildered when your installation from source fails for some unknown reason because you're missing a dependency, when you install from rpm, it tells you exactly what prerequisite programs you need first.





So, what to do about it:
A) you can find the right rpm of perl(DBI) and do it that way
B) install both of perl(DBI) and MySQL from tarball/source (a lot of hassle: not recommended)
C) install the MySQL rpm with the option --nodeps, e.g.:
rpm -ivh --nodeps MySQL-client-5.0.27-0.glibc23.i386.rpm

...This tells RPM package manager to ignore the fact that it cannot find perl(DBI) in the database, because you know you've installed it from source.

A) is generally best practice, and will save headaches in the long run, but C) will probably work at the moment. Using C) can be risky if you're not careful about what it is you're doing.

Does that make sense?


I have another question concerning the PHP installation along with MySQL, which by the way installed without a problem. Thanks again.

I downloaded PHP, (I could only find this in tarball format)and according to my book, the command for basic installation to install PHP with Apache and MySQL is:

./configure --prefix=/usr/local/php --with-mysqli=/usr/local/mysql/bin/mysql_config --with-apxs2=/usr/local/apache2/bin/apxs

I already have apache installed and the apxs directory exists. However, the mysql_config executable isn't on my system. I did a search for mysqli and found this:

/usr/bin/mysqlimport
/usr/share/man/man1/mysqlimport.1.gz
/usr/local/php-5.2.0/ext/mysqli
/usr/local/php-5.2.0/ext/mysqli/TODO
/usr/local/php-5.2.0/ext/mysqli/mysqli_nonapi.c
/usr/local/php-5.2.0/ext/mysqli/mysqli_embedded.c
/usr/local/php-5.2.0/ext/mysqli/mysqli_report.c
/usr/local/php-5.2.0/ext/mysqli/mysqli_report.h
/usr/local/php-5.2.0/ext/mysqli/mysqli_api.c
/usr/local/php-5.2.0/ext/mysqli/tests
/usr/local/php-5.2.0/ext/mysqli/tests/024.phpt
/usr/local/php-5.2.0/ext/mysqli/tests/025.phpt
/usr/local/php-5.2.0/ext/mysqli/tests/bug38003.phpt
/usr/local/php-5.2.0/ext/mysqli/tests/026.phpt
/usr/local/php-5.2.0/ext/mysqli/tests/bug32405.phpt
/usr/local/php-5.2.0/ext/mysqli/tests/027.phpt
/usr/local/php-5.2.0/ext/mysqli/tests/028.phpt
/usr/local/php-5.2.0/ext/mysqli/tests/029.phpt
/usr/local/php-5.2.0/ext/mysqli/tests/030.phpt
/usr/local/php-5.2.0/ext/mysqli/tests/031.phpt
/usr/local/php-5.2.0/ext/mysqli/tests/032.phpt
/usr/local/php-5.2.0/ext/mysqli/tests/bug34785.phpt
/usr/local/php-5.2.0/ext/mysqli/tests/033.phpt
/usr/local/php-5.2.0/ext/mysqli/tests/034.phpt
/usr/local/php-5.2.0/ext/mysqli/tests/035.phpt
/usr/local/php-5.2.0/ext/mysqli/tests/036.phpt
/usr/local/php-5.2.0/ext/mysqli/tests/037.phpt
/usr/local/php-5.2.0/ext/mysqli/tests/038.phpt
/usr/local/php-5.2.0/ext/mysqli/tests/bug31141.phpt
/usr/local/php-5.2.0/ext/mysqli/tests/039.phpt
/usr/local/php-5.2.0/ext/mysqli/tests/040.phpt
/usr/local/php-5.2.0/ext/mysqli/tests/bug33263.phpt
/usr/local/php-5.2.0/ext/mysqli/tests/041.phpt
/usr/local/php-5.2.0/ext/mysqli/tests/bug29311.phpt
/usr/local/php-5.2.0/ext/mysqli/tests/042.phpt
/usr/local/php-5.2.0/ext/mysqli/tests/043.phpt
/usr/local/php-5.2.0/ext/mysqli/tests/044.phpt
/usr/local/php-5.2.0/ext/mysqli/tests/045.phpt
/usr/local/php-5.2.0/ext/mysqli/tests/bug35759.phpt
/usr/local/php-5.2.0/ext/mysqli/tests/046.phpt
/usr/local/php-5.2.0/ext/mysqli/tests/047.phpt
/usr/local/php-5.2.0/ext/mysqli/tests/048.phpt
/usr/local/php-5.2.0/ext/mysqli/tests/049.phpt
/usr/local/php-5.2.0/ext/mysqli/tests/050.phpt
/usr/local/php-5.2.0/ext/mysqli/tests/051.phpt
/usr/local/php-5.2.0/ext/mysqli/tests/052.phpt
/usr/local/php-5.2.0/ext/mysqli/tests/053.phpt
/usr/local/php-5.2.0/ext/mysqli/tests/054.phpt
/usr/local/php-5.2.0/ext/mysqli/tests/055.phpt
/usr/local/php-5.2.0/ext/mysqli/tests/bug33090.phpt
/usr/local/php-5.2.0/ext/mysqli/tests/056.phpt
/usr/local/php-5.2.0/ext/mysqli/tests/057.phpt
/usr/local/php-5.2.0/ext/mysqli/tests/058.phpt
/usr/local/php-5.2.0/ext/mysqli/tests/059.phpt
/usr/local/php-5.2.0/ext/mysqli/tests/bug35517.phpt
/usr/local/php-5.2.0/ext/mysqli/tests/bug36420.phpt
/usr/local/php-5.2.0/ext/mysqli/tests/060.phpt
/usr/local/php-5.2.0/ext/mysqli/tests/061.phpt
/usr/local/php-5.2.0/ext/mysqli/tests/062.phpt
/usr/local/php-5.2.0/ext/mysqli/tests/skipifnotemb.inc
/usr/local/php-5.2.0/ext/mysqli/tests/bug31668.phpt
/usr/local/php-5.2.0/ext/mysqli/tests/063.phpt
/usr/local/php-5.2.0/ext/mysqli/tests/064.phpt
/usr/local/php-5.2.0/ext/mysqli/tests/065.phpt
/usr/local/php-5.2.0/ext/mysqli/tests/066.phpt
/usr/local/php-5.2.0/ext/mysqli/tests/067.phpt
/usr/local/php-5.2.0/ext/mysqli/tests/068.phpt
/usr/local/php-5.2.0/ext/mysqli/tests/bug34810.phpt
/usr/local/php-5.2.0/ext/mysqli/tests/bug36802.phpt
/usr/local/php-5.2.0/ext/mysqli/tests/001.phpt
/usr/local/php-5.2.0/ext/mysqli/tests/skipif.inc
/usr/local/php-5.2.0/ext/mysqli/tests/bug36745.phpt
/usr/local/php-5.2.0/ext/mysqli/tests/002.phpt
/usr/local/php-5.2.0/ext/mysqli/tests/071.phpt
/usr/local/php-5.2.0/ext/mysqli/tests/003.phpt
/usr/local/php-5.2.0/ext/mysqli/tests/072.phpt
/usr/local/php-5.2.0/ext/mysqli/tests/004.phpt
/usr/local/php-5.2.0/ext/mysqli/tests/073.phpt
/usr/local/php-5.2.0/ext/mysqli/tests/bug37090.phpt
/usr/local/php-5.2.0/ext/mysqli/tests/005.phpt
/usr/local/php-5.2.0/ext/mysqli/tests/006.phpt
/usr/local/php-5.2.0/ext/mysqli/tests/007.phpt
/usr/local/php-5.2.0/ext/mysqli/tests/bug28817.phpt
/usr/local/php-5.2.0/ext/mysqli/tests/skipifemb.inc
/usr/local/php-5.2.0/ext/mysqli/tests/008.phpt
/usr/local/php-5.2.0/ext/mysqli/tests/009.phpt
/usr/local/php-5.2.0/ext/mysqli/tests/bug30967.phpt
/usr/local/php-5.2.0/ext/mysqli/tests/connect.inc
/usr/local/php-5.2.0/ext/mysqli/tests/010.phpt
/usr/local/php-5.2.0/ext/mysqli/tests/011.phpt
/usr/local/php-5.2.0/ext/mysqli/tests/012.phpt
/usr/local/php-5.2.0/ext/mysqli/tests/013.phpt
/usr/local/php-5.2.0/ext/mysqli/tests/bug33491.phpt
/usr/local/php-5.2.0/ext/mysqli/tests/014.phpt
/usr/local/php-5.2.0/ext/mysqli/tests/015.phpt
/usr/local/php-5.2.0/ext/mysqli/tests/016.phpt
/usr/local/php-5.2.0/ext/mysqli/tests/017.phpt
/usr/local/php-5.2.0/ext/mysqli/tests/018.phpt
/usr/local/php-5.2.0/ext/mysqli/tests/bug35103.phpt
/usr/local/php-5.2.0/ext/mysqli/tests/019.phpt
/usr/local/php-5.2.0/ext/mysqli/tests/bug36949.phpt
/usr/local/php-5.2.0/ext/mysqli/tests/020.phpt
/usr/local/php-5.2.0/ext/mysqli/tests/021.phpt
/usr/local/php-5.2.0/ext/mysqli/tests/022.phpt
/usr/local/php-5.2.0/ext/mysqli/tests/023.phpt
/usr/local/php-5.2.0/ext/mysqli/package.xml
/usr/local/php-5.2.0/ext/mysqli/config.m4
/usr/local/php-5.2.0/ext/mysqli/config.w32
/usr/local/php-5.2.0/ext/mysqli/mysqli.dsp
/usr/local/php-5.2.0/ext/mysqli/mysqli_driver.c
/usr/local/php-5.2.0/ext/mysqli/mysqli_exception.c
/usr/local/php-5.2.0/ext/mysqli/php_mysqli.h
/usr/local/php-5.2.0/ext/mysqli/mysqli_prop.c
/usr/local/php-5.2.0/ext/mysqli/mysqli_repl.c
/usr/local/php-5.2.0/ext/mysqli/mysqli_fe.c
/usr/local/php-5.2.0/ext/mysqli/CREDITS
/usr/local/php-5.2.0/ext/mysqli/mysqli.c
/usr/local/php-5.2.0/ext/mysqli/mysqli_warning.c


The book doesn't go into any detail as to what this executable is for and when I search for it on the Internet, I can only find it being refered to in forums that do not explain what it is.

Does anything I have in on my computer pertain to the mysqli that I may need in configuring PHP with mysql support?

144419855310001 12-11-2006 05:48 PM
In this case the "whereis" command comes in useful.

Type e.g. "whereis mysql" or "whereis mysqli" etc., as appropriate.
This will tell you, if the program is on your system, firstly: where the executable is, then where the source is, and finally the man pages.

for example:
Quote:
[144419855310001@waikiki_beach ~]$ whereis vim
vim: /usr/bin/vim /usr/share/vim /usr/share/man/man1/vim.1.gz
So what happens when you type "whereis mysql_config" / etc?

tekmann33 12-12-2006 09:06 AM
The command doesn't seem to find anything.

[root@BriansRH bclanton]# /usr/bin/whereis mysql_config
mysql_config:

tekmann33 12-12-2006 10:17 AM
Just as a test, I downloaded and unzipped/untarred a version of mysql in tarball form and looked for a mysql_config.

[root@BriansRH php-5.2.0]# locate mysql_config
/usr/local/mysql-standard-5.0.27-linux-i686-icc-glibc23/bin/mysql_config
/usr/local/mysql-standard-5.0.27-linux-i686-icc-glibc23/man/man1/mysql_config.1


The only problem is that it fails to initialize the tables upon installing the database:

[root@BriansRH mysql]# scripts/mysql_install_db --user=mysql
Installing all prepared tables
./bin/mysqld: error while loading shared libraries: libstdc++.so.6: cannot open
shared object file: No such file or directory
./bin/mysql_create_system_tables: line 766: 3816 Broken pipe cat <<END_OF_DATA
use mysql;
set table_type=myisam;
$c_d
$i_d

$c_h
$i_h

$c_u
$i_u

$c_f
$i_f

$c_t
$c_c

$c_ht
$c_hc
$c_hr
$c_hk

$c_tzn
$i_tzn
$c_tz
$i_tz
$c_tzt
$i_tzt
$c_tztt
$i_tztt
$c_tzls
$i_tzls

$c_p
$c_pp

END_OF_DATA

Installation of system tables failed!

Examine the logs in ./data for more information.
You can also try to start the mysqld daemon with:
./bin/mysqld --skip-grant &
You can use the command line tool
./bin/mysql to connect to the mysql
database and look at the grant tables:

shell> ./bin/mysql -u root mysql
mysql> show tables

Try 'mysqld --help' if you have problems with paths. Using --log
gives you a log in ./data that may be helpful.

The latest information about MySQL is available on the web at
http://www.mysql.com
Please consult the MySQL manual section: 'Problems running mysql_install_db',
and the manual section that describes problems on your OS.
Another information source is the MySQL email archive.
Please check all of the above before mailing us!
And if you do mail us, you MUST use the ./bin/mysqlbug script!


I would rather use the rpm version for reason that you mentioned previously. Is there another way to configure PHP without using the mysql_config command with the PHP configure statement?

144419855310001 12-12-2006 01:12 PM
Quote:
Is there another way to configure PHP without using the mysql_config command with the PHP configure statement?
Mmmm... that's getting a little bit out of my depth. I'm sure there's an easier way than that though


...Just found the answer. The *other* important thing to remember when you're mixing programs you've compiled yourself and rpms is that of "devel" rpms.

If you ever wish to install something from source that is dependent on something you have installed from rpm, you need to install the "devel" package of that rpm too.

For almost every rpm, there is an associated devel package. Say you wish to compile "Z", which requires "Y", which you've installed from rpm, you need to install "Y-devel.rpm" as well as just "Y.rpm".

I searched rpm.pbone.net (v. useful website for ironing out dependency problems) for mysql_config on Redhat 9, and sure enough, it brought up mysqlclient-*-devel. Install the right devel package(s) and everything should be fine.

chrism01 12-12-2006 05:50 PM
In the long run, you'll find life easier if you use a reasonably current release of RH.
V9 is very old and not supported. The current equiv is RH Fedora Core v6 http://fedora.redhat.com/ (effectively RH v15).
Most current SW assumes a recent/current OS.

tekmann33 12-13-2006 09:46 AM
I have finally installed everything with success.

I opted to install everything via tarball. Installing via rppm was just becomming too frustrating, probably more from my lack of understanding at this point.

I would install the perl(DBI) rpm and a and a list of library dependencies would appear. I would acquire the libraris and try to install them, and different dependencies would list. I did this for a few iterations and gave up on rpm.

I found a source file for mysql and it installed and initialized the tables without a problem. It even created the elusive mysql_config executable. After that everything wasn't difficult. I installed perl(DBI), apache, and the libxml library without a hitch.

i agree with chrism01, it might be time to upgrade.

Thanks for everyone's input.

chrism01 12-13-2006 05:38 PM
Also, in modern distros, rpms (or any other pkg system eg .deb) all come with the appropriate pkg mgr that automatically take care of dependencies eg yum / yumes / synaptic.
I'd recommend using those after you upgrade. These mgrs enable you to also cleanly remove stuff without breaking things because they track dependencies.
BTW, RH9 -> FC6 is too big a jump to 'upgrade'; do a clean install if you want to preserve your sanity. ;)


All times are GMT -5. The time now is 05:32 PM.