Обсуждение: PostgreSQL perl / libpq.so.2 problem - again :(
Hello All,
I recently installed PostgreSQL version 7.1.2 on my system running Linux
6.2 and perl 5.6.1. Oddly, when I installed the rpm file
postgresql-perl-7.1.2-4PGDG.i386.rpm, it installed an older version of
perl into /usr/lib/perl5/5.00503 (compiled apparently for Linux running
on i386, while my version of perl is compiled for Linux running on
i686). Now, when I try to run a perl script that attempts to access a
postgresql database through DBI::Pg, I get the following error message:
[tc0001] Can't load
'/usr/apps/lib/perl5/site_perl/5.6.1/i686-linux/auto/DBD/Pg/Pg.so' for
module DBD::Pg: libpq.so.2: cannot open shared object file: No such file
or directory at /usr/lib/perl5/5.00503/i386-linux/DynaLoader.pm line 169
([tc0001] refers to a Parallel Virtual Machine task #).
The libpq.so.2 file is there, in /usr/lib. When I run ldd on Pg.so, I
get the following output, which apparently tells me that everything is
"OK":
libpq.so.2 => /usr/lib/libpq.so.2 (0x2aab9000)
libc.so.6 => /lib/libc.so.6 (0x2aacd000)
libssl.so.0 => /usr/lib/libssl.so.0 (0x2abc2000)
libcrypto.so.0 => /usr/lib/libcrypto.so.0 (0x2abef000)
libcrypt.so.1 => /lib/libcrypt.so.1 (0x2acae000)
libresolv.so.2 => /lib/libresolv.so.2 (0x2acdb000)
libnsl.so.1 => /lib/libnsl.so.1 (0x2acea000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x55555000)
I ran ldconfig without any success. I did check the [extensive]
discussion of the missing libpq.so.2 file at
http://postgresql.bnv-bamberg.de/mhonarc/pgsql-general/2000-11/msg00188.html,
and my file libpq.so.2 (according to the solution suggested by Lamar on
the forum) is already symlinked to libpq.so.2.1.
Further suggestions, anyone?
Thanks!
Alex
This might sound like a flame, but it isn't meant to be. Uninstall the rpm
packages that are giving you trouble and reinstall them from source. For me,
rpm's are just grief, especially for apps that I'm going to do a lot of
configuration anyway. That's why I use slackware where I can, but even on our
Mandrake server (not my choice), I convinced the admin to let me compile
postgresql and apache from source, both to get the most recent updates
immediately and so they could be optimized for that machine.
OTOH, if you can get the rpm's to work, by all means more power to you.
Alexander Turchin <aturchin%chip.org@interlock.lexmark.com> on 07/05/2001
06:18:35 PM
To: pgsql-general%postgresql.org@interlock.lexmark.com
cc: (bcc: Wesley Sheldahl/Lex/Lexmark)
Subject: [GENERAL] PostgreSQL perl / libpq.so.2 problem - again :(
Hello All,
I recently installed PostgreSQL version 7.1.2 on my system running Linux
6.2 and perl 5.6.1. Oddly, when I installed the rpm file
postgresql-perl-7.1.2-4PGDG.i386.rpm, it installed an older version of
perl into /usr/lib/perl5/5.00503 (compiled apparently for Linux running
on i386, while my version of perl is compiled for Linux running on
i686). Now, when I try to run a perl script that attempts to access a
postgresql database through DBI::Pg, I get the following error message:
[tc0001] Can't load
'/usr/apps/lib/perl5/site_perl/5.6.1/i686-linux/auto/DBD/Pg/Pg.so' for
module DBD::Pg: libpq.so.2: cannot open shared object file: No such file
or directory at /usr/lib/perl5/5.00503/i386-linux/DynaLoader.pm line 169
([tc0001] refers to a Parallel Virtual Machine task #).
The libpq.so.2 file is there, in /usr/lib. When I run ldd on Pg.so, I
get the following output, which apparently tells me that everything is
"OK":
libpq.so.2 => /usr/lib/libpq.so.2 (0x2aab9000)
libc.so.6 => /lib/libc.so.6 (0x2aacd000)
libssl.so.0 => /usr/lib/libssl.so.0 (0x2abc2000)
libcrypto.so.0 => /usr/lib/libcrypto.so.0 (0x2abef000)
libcrypt.so.1 => /lib/libcrypt.so.1 (0x2acae000)
libresolv.so.2 => /lib/libresolv.so.2 (0x2acdb000)
libnsl.so.1 => /lib/libnsl.so.1 (0x2acea000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x55555000)
I ran ldconfig without any success. I did check the [extensive]
discussion of the missing libpq.so.2 file at
http://postgresql.bnv-bamberg.de/mhonarc/pgsql-general/2000-11/msg00188.html,
and my file libpq.so.2 (according to the solution suggested by Lamar on
the forum) is already symlinked to libpq.so.2.1.
Further suggestions, anyone?
Thanks!
Alex
---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly
On Thursday 05 July 2001 18:18, Alexander Turchin wrote: > I recently installed PostgreSQL version 7.1.2 on my system running Linux > 6.2 and perl 5.6.1. Oddly, when I installed the rpm file > postgresql-perl-7.1.2-4PGDG.i386.rpm, it installed an older version of > perl into /usr/lib/perl5/5.00503 (compiled apparently for Linux running > on i386, while my version of perl is compiled for Linux running on > i686). Now, when I try to run a perl script that attempts to access a > postgresql database through DBI::Pg, I get the following error message: Ok. 1.) Red Hat 6.2 doesn't ship by default with Perl 5.6. 2.) The RHL 6.2 RPMset is compiled to run on a vanilla RHL 6.2. 3.) The postgresql-perl RPM doesn't contain the DBI::Pg module -- it contains the non-DBI/DBD Pg module. 4.) The RHL 6.2 RPMset is compiled for i386 because people running this on 486's shouldn't be penalized. (Yes, there _are_ people running stuff for development on 486's. All the world isn't Pentium III.) If you want a version of the RPM's for your particular setup, you will need to rebuild from the source RPM. This is accomplished rather easily, providing that you have a full development environment on your machine. See the rebuilding section of /usr/doc/postgresql-7.1.2/README.rpm-dist for more information. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
On Friday 06 July 2001 09:04, wsheldah@lexmark.com wrote: > This might sound like a flame, but it isn't meant to be. Uninstall the rpm > packages that are giving you trouble and reinstall them from source. For > me, rpm's are just grief, especially for apps that I'm going to do a lot of > configuration anyway. For a machine that has only RPM-installed packages, the RPM's can be more convenient. > compile postgresql and apache from source, both to get the most recent > updates immediately and so they could be optimized for that machine. As the PostgreSQL release cycle is rather slower than much software, this isn't really an issue for PostgreSQL. Patience is still a virtue. > OTOH, if you can get the rpm's to work, by all means more power to you. RPM offers more to users than just convenience. But, if you're not convinced, I'm not going to argue with you. In my case, I used the RPM's before I started maintaining the RPM's because I don't install development tools on production servers -- and at the time Ididn't have a development server to build on. I now have enough boxen to do the development with -- but I still prefer the RPM way of doing things, as it results in a more consistent system. And I take great pains toleave my development machines in 'out-of-the-box' condition (except for security updates) so that the RPM's I build are usable by the most people. Otherwise, you will have to rebuild the RPMset from the source RPM for your custom setup. But, if you start installing core OS packages from source on an RPM box, you will likely need to install all dependent packages from source as well, as the RPM database won't have the correct dependency information. In the example that started this thread, had Perl 5.6 been installed as RPM, the postgresql-perl RPM installation should have barfed, as it depends upon the perl version registered with the RPM database to equal 5.00503 -- not greater and not less. But perl 5.6 was installed from source -- and the RPM database dependencies we're updated -- which could cause more problems than for just the postgresql-perl RPM, as any other RPMs that depend upon perl=5.00503 will install silently to the older perl directory, which will be incorrect. On a related note, I no longer have RedHat 6.2 or 7.0 boxen -- Red Hat 7.1 is so much more stable (and so much faster!) that I have migrated all but my production server to RH 7.1 --and the production server will get the upgrade next. If anyone wants to donate a old hard drive or two to see older or other distributions supported, I won't argue :-). The installation of Red Hat necessary to build the RPMset varies, but is almost always greater than 1GB -- a 2 or 3 GB hard drive is enough to install a development set on -- and I will continue support for those distributions as long as the hard drive lives..... So, unless things change, future PostgreSQL binary RPMsets will be built only for RHL 7.1 by me -- others are already building Mandrake 7.2 and 8.0 sets. You can rebuild from the source RPM fairly easily, though, as long as you have at least RPM version 3.0.5. Instructions are in the README.rpm-dist. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
Hi all, Are you familiar with Symantec Ghost? The way I work I keep fresh installed versions of Mandrake 8.0, Win NT (with SP6a), Solaris 8.0 INTEL, etc, as compressed image files. When it comes time to build software on a "freshly installed" machine it takes just under 10 minutes to restore the appropriate image to a hard drive with Ghost. Works well for me. What do you guys think, good approach? :-) Regards and best wishes, Justin Clift Lamar Owen wrote: > > On Friday 06 July 2001 09:04, wsheldah@lexmark.com wrote: > > This might sound like a flame, but it isn't meant to be. Uninstall the rpm > > packages that are giving you trouble and reinstall them from source. For > > me, rpm's are just grief, especially for apps that I'm going to do a lot of > > configuration anyway. > > For a machine that has only RPM-installed packages, the RPM's can be more > convenient. > > > compile postgresql and apache from source, both to get the most recent > > updates immediately and so they could be optimized for that machine. > > As the PostgreSQL release cycle is rather slower than much software, this > isn't really an issue for PostgreSQL. Patience is still a virtue. > > > OTOH, if you can get the rpm's to work, by all means more power to you. > > RPM offers more to users than just convenience. But, if you're not > convinced, I'm not going to argue with you. > > In my case, I used the RPM's before I started maintaining the RPM's because I > don't install development tools on production servers -- and at the time > Ididn't have a development server to build on. I now have enough boxen to do > the development with -- but I still prefer the RPM way of doing things, as it > results in a more consistent system. And I take great pains toleave my > development machines in 'out-of-the-box' condition (except for security > updates) so that the RPM's I build are usable by the most people. > > Otherwise, you will have to rebuild the RPMset from the source RPM for your > custom setup. > > But, if you start installing core OS packages from source on an RPM box, you > will likely need to install all dependent packages from source as well, as > the RPM database won't have the correct dependency information. > > In the example that started this thread, had Perl 5.6 been installed as RPM, > the postgresql-perl RPM installation should have barfed, as it depends upon > the perl version registered with the RPM database to equal 5.00503 -- not > greater and not less. But perl 5.6 was installed from source -- and the RPM > database dependencies we're updated -- which could cause more problems than > for just the postgresql-perl RPM, as any other RPMs that depend upon > perl=5.00503 will install silently to the older perl directory, which will be > incorrect. > > On a related note, I no longer have RedHat 6.2 or 7.0 boxen -- Red Hat 7.1 is > so much more stable (and so much faster!) that I have migrated all but my > production server to RH 7.1 --and the production server will get the upgrade > next. If anyone wants to donate a old hard drive or two to see older or > other distributions supported, I won't argue :-). The installation of Red > Hat necessary to build the RPMset varies, but is almost always greater than > 1GB -- a 2 or 3 GB hard drive is enough to install a development set on -- > and I will continue support for those distributions as long as the hard drive > lives..... > > So, unless things change, future PostgreSQL binary RPMsets will be built only > for RHL 7.1 by me -- others are already building Mandrake 7.2 and 8.0 sets. > You can rebuild from the source RPM fairly easily, though, as long as you > have at least RPM version 3.0.5. Instructions are in the README.rpm-dist. > -- > Lamar Owen > WGCR Internet Radio > 1 Peter 4:11 > > ---------------------------(end of broadcast)--------------------------- > TIP 3: if posting/reading through Usenet, please send an appropriate > subscribe-nomail command to majordomo@postgresql.org so that your > message can get through to the mailing list cleanly
On Saturday 07 July 2001 11:39, Justin Clift wrote: > Are you familiar with Symantec Ghost? Yes. Is there now a version that doesn't require Windows installed? :-) I own the Windows version. I've used it numerous times for that. However, I prefer to simply unlock a drive slide and slide a new one in :-). > Works well for me. What do you guys think, good approach? It or the VMware approach are both good approaches -- but my development servers do other things that are mission critical overnight -- and playing on my backup/restore setup is against my policy. So I pull the slide out, and pop the dev slide in when I need to do 'playing' (like RPM building....). This way I can also use more modern versions of certain packages on my backup/restore and utility systems (for hot failover and the like) and keep pristine OS installs laying around for RPM building. 3.2GB harddrives are pretty cheap these days -- I just don't have enough of them on hand, and have a budget to follow..... However, I can't really afford the VMware approach at the moment for the use I would put VMware to.... :-) I sure would like to have their Enterprise version -- just being able to have fine-grained resource management like that is so nice -- makes one wish for an S/390..... -- Lamar Owen WGCR Internet Radio 1 Peter 4:11