Thread: libpq.so.2.0 problem
Hello, I recently installed Redhat 7.0 and Postgres 7.0.2 on a new server... the install (of both) went better than expected, and I was able to get DBD and DBI up and running. When I copied my scripts (perl) over to the new server none ran. The error I received was "error in loading shared libraries libpq.so.2.0: cannot open shared object file: No such file or directory". So after an extensive search through the docs, faqs and maillist archive, I tried making an entry in /etc/ld.so.conf to reflect the postgres library (/usr/lib/pgsql for me) and also included /usr/include/pgsql just in case. Then I ran ldconfig to register everything. No luck, nothing ran and I received the same error. I found a copy of the file libpq.so.2.0 on another machine (Redhat 6.2 upgraded to 7.0), copied it over to the /usr/lib/pgsql directory, re-ran ldconfig, but still the same error. I'm sure I'm in over my head at this point and any help to get my scripts up and running would be greatly appreciated! Thanks! -Jim
James Hall <James.Hall@RadioShack.com> writes: > I recently installed Redhat 7.0 and Postgres 7.0.2 on a new server... the > install (of both) went better than expected, and I was able to get DBD and > DBI up and running. When I copied my scripts (perl) over to the new server > none ran. The error I received was "error in loading shared libraries > libpq.so.2.0: cannot open shared object file: No such file or > directory". What refers to that file? -- Trond Eivind Glomsrød Red Hat, Inc.
Thanks for the quick responses! I have not checked the errata page at Redhat but am headed there now. Trond, if I understand your question correctly (and chances are I don't), The error message (exactly) is: Sample_Eval.cgi: error while loading shared libraries: libpq.so.2.0: cannot open shared object file: No such file or directory This error message is from apaches error_log (/var/log/http) and Sample_Eval.cgi is a script that has includes to stdio.h, stdlib.h, and libpq-fe.h ldconfig -p shows no listing for libpq.so.2.0 at all. HTHs... -Jim -----Original Message----- From: teg@redhat.com [mailto:teg@redhat.com] Sent: Tuesday, November 07, 2000 10:01 AM To: James Hall Cc: pgsql-general@postgresql.org Subject: Re: [GENERAL] libpq.so.2.0 problem James Hall <James.Hall@RadioShack.com> writes: > I recently installed Redhat 7.0 and Postgres 7.0.2 on a new server... the > install (of both) went better than expected, and I was able to get DBD and > DBI up and running. When I copied my scripts (perl) over to the new server > none ran. The error I received was "error in loading shared libraries > libpq.so.2.0: cannot open shared object file: No such file or > directory". What refers to that file? -- Trond Eivind Glomsrød Red Hat, Inc.
James Hall <James.Hall@RadioShack.com> writes: > Thanks for the quick responses! > > I have not checked the errata page at Redhat but am headed there now. Good, but you won't find anything for postgresql there... > > Trond, if I understand your question correctly (and chances are I don't), > > The error message (exactly) is: > Sample_Eval.cgi: error while loading shared libraries: libpq.so.2.0: cannot > open shared object file: No such file or directory > > This error message is from apaches error_log (/var/log/http) and > Sample_Eval.cgi is a script that has includes to stdio.h, stdlib.h, and > libpq-fe.h Script which includes headers? > ldconfig -p shows no listing for libpq.so.2.0 at all. Red Hat Linux 7 comes with libpq.so.2.1. -- Trond Eivind Glomsrød Red Hat, Inc.
Trond Eivind Glomsrød wrote:
> James Hall <James.Hall@RadioShack.com> writes:
> > I recently installed Redhat 7.0 and Postgres 7.0.2 on a new server... the
> > install (of both) went better than expected, and I was able to get DBD and
> > DBI up and running. When I copied my scripts (perl) over to the new server
> > none ran. The error I received was "error in loading shared libraries
> > libpq.so.2.0: cannot open shared object file: No such file or
> > directory".
> What refers to that file?
The perl-DBD-Pg package. The version of this package installed is not
given -- and that would be critical, here, as there are a number of
versions to choose from, according to rpmfind. The version likely to be
used would be perl-DBD-pg-0.91-2, which was built by RedHat for the CPAN
archives -- and the dependency list for this package is:
Provides:
perl-DBD-Pg
Pg.so
Requires:
perl
ld-linux.so.2
libc.so.6
libpq.so.2.0
Only a Connectiva Linux perl-DBD-Pg RPM is being built (according to
rpmfind.net, at least) against PostgreSQL 7 as of yet -- this would be
perl-DBD-Pg-0.93-7cl. But I would think there would be more of a
problem with Perl 5.6 versus 5.005 than any other issue.
Symlink libpq.so.2.0 to libpq.so.2.1.
This is the problem I have referred to in the past that causes problems
with PHP RPM's as well.
Or, if DBD::Pg was built from source on the previous machine, and
binaries simply moved over, that would also cause this.
And I'm working on my end of the fix -- copying libpq.so.2.x to
libpq.so.2 instead of symlinking. But this will only help future
packages that are built against PostgreSQL RPM's after I do that.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11
Lamar Owen <lamar.owen@wgcr.org> writes: > Trond Eivind Glomsrød wrote: > > James Hall <James.Hall@RadioShack.com> writes: > > > I recently installed Redhat 7.0 and Postgres 7.0.2 on a new server... the > > > install (of both) went better than expected, and I was able to get DBD and > > > DBI up and running. When I copied my scripts (perl) over to the new server > > > none ran. The error I received was "error in loading shared libraries > > > libpq.so.2.0: cannot open shared object file: No such file or > > > directory". > > > What refers to that file? > > The perl-DBD-Pg package. I don't think we ship that... > The version of this package installed is not > given -- and that would be critical, here, as there are a number of > versions to choose from, according to rpmfind. The version likely to be > used would be perl-DBD-pg-0.91-2, which was built by RedHat for the CPAN > archives An older version, I think - at least, I don't seem to find it now. > Symlink libpq.so.2.0 to libpq.so.2.1. The application itself is linked with libpq.so.2.0 instead of libpq.so.2, which would solve the problem... -- Trond Eivind Glomsrød Red Hat, Inc.
Trond Eivind Glomsrød wrote: > Lamar Owen <lamar.owen@wgcr.org> writes: > > The perl-DBD-Pg package. > I don't think we ship that... Not with RH 7 at least. > > Symlink libpq.so.2.0 to libpq.so.2.1. > The application itself is linked with libpq.so.2.0 instead of > libpq.so.2, which would solve the problem... This is a thing with the find-requires script. Since ld.so is providing the version linkage information, and since it walks the symlinks until it finds a real lib.... You see the problem? I'm sure that libpq.so is not the only library extant that can trigger this sort of thing. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
Lamar Owen <lamar.owen@wgcr.org> writes: > Trond Eivind Glomsrød wrote: > > Lamar Owen <lamar.owen@wgcr.org> writes: > > > The perl-DBD-Pg package. > > > I don't think we ship that... > > Not with RH 7 at least. > > > > Symlink libpq.so.2.0 to libpq.so.2.1. > > > The application itself is linked with libpq.so.2.0 instead of > > libpq.so.2, which would solve the problem... > > This is a thing with the find-requires script. No, this wasn't at the rpm level. -- Trond Eivind Glomsrød Red Hat, Inc.
Trond Eivind Glomsrød wrote: > Lamar Owen <lamar.owen@wgcr.org> writes: > > > The application itself is linked with libpq.so.2.0 instead of > > > libpq.so.2, which would solve the problem... > > This is a thing with the find-requires script. > No, this wasn't at the rpm level. I see what you're talking about, now. Of course, this is a little different from the problem I mentioned earlier -- this is a runtime issue, whereas the earlier was an install-time issue. And that complicates things. But the install-time issue also exists -- although, even if installation is allowed, you can still get hung up with the run-time issue. I think that by packaging the RPM's to include libpq.so.2.x as simply libpq.so.2 (as long as 2.x's are link-compatible), I can help alleviate this problem for future builds. The consensus within the PostgreSQL developer community is that 'we version our libs. If an OS has a problem with that, and others do not, then that isn't our problem.' Source-centric, I know. But it's just the way it is. The RPM distribution can get away with the copy over the symlink thanks to the version information being stored in the rpm database. But, no, this isn't necessarily an RPM issue per se -- it is a general library versioning issue. James, you can simply symlink libpq.so.2.0 to libpq.so.2.1 to get your stuff running. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
Lamar Owen writes: > I think that by packaging the RPM's to include libpq.so.2.x as simply > libpq.so.2 (as long as 2.x's are link-compatible), I can help alleviate > this problem for future builds. > > The consensus within the PostgreSQL developer community is that 'we > version our libs. If an OS has a problem with that, and others do not, > then that isn't our problem.' Source-centric, I know. But it's just > the way it is. Um, what do you suggest that we do? This is how you create shared libraries on GNU/Linux. Even Red Hat seems to think so: peter ~$ ls -l /usr/lib/libjpeg* -rw-r--r-- 1 root root 166028 Jul 13 20:51 /usr/lib/libjpeg.a -rwxr-xr-x 1 root root 470 Jul 13 20:51 /usr/lib/libjpeg.la* lrwxrwxrwx 1 root root 17 Oct 1 03:27 /usr/lib/libjpeg.so -> libjpeg.so.62.0.0* lrwxrwxrwx 1 root root 17 Oct 1 03:27 /usr/lib/libjpeg.so.62 -> libjpeg.so.62.0.0* -rwxr-xr-x 1 root root 141528 Jul 13 20:51 /usr/lib/libjpeg.so.62.0.0* ...and even Libtool: peter ~/gnu/lib$ ls -l total 112 -rw-r--r-- 1 peter peter 54368 Nov 1 21:56 libltdl.a -rwxr-xr-x 1 peter peter 704 Nov 1 21:56 libltdl.la* lrwxrwxrwx 1 peter peter 16 Nov 1 21:56 libltdl.so -> libltdl.so.0.2.0* lrwxrwxrwx 1 peter peter 16 Nov 1 21:56 libltdl.so.0 -> libltdl.so.0.2.0* -rwxr-xr-x 1 peter peter 56176 Nov 1 21:56 libltdl.so.0.2.0* There *might* be a problem with the -soname thing, but I recall that that patch came from someone with SuSE, so they probably knew what they were doing. The symlink order will not be changed, other improvements are welcome. -- Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/
>James, you can simply symlink libpq.so.2.0 to libpq.so.2.1 to get your >stuff running. That's exactly what I did and everything runs great now! Thank you very much (Trond, Lamar) for all your help and 2 great products! -Jim -----Original Message----- From: Lamar Owen [mailto:lamar.owen@wgcr.org] Sent: Tuesday, November 07, 2000 12:14 PM To: Trond Eivind Glomsrød Cc: James Hall; pgsql-general@postgresql.org Subject: Re: [GENERAL] libpq.so.2.0 problem Trond Eivind Glomsrød wrote: > Lamar Owen <lamar.owen@wgcr.org> writes: > > > The application itself is linked with libpq.so.2.0 instead of > > > libpq.so.2, which would solve the problem... > > This is a thing with the find-requires script. > No, this wasn't at the rpm level. I see what you're talking about, now. Of course, this is a little different from the problem I mentioned earlier -- this is a runtime issue, whereas the earlier was an install-time issue. And that complicates things. But the install-time issue also exists -- although, even if installation is allowed, you can still get hung up with the run-time issue. I think that by packaging the RPM's to include libpq.so.2.x as simply libpq.so.2 (as long as 2.x's are link-compatible), I can help alleviate this problem for future builds. The consensus within the PostgreSQL developer community is that 'we version our libs. If an OS has a problem with that, and others do not, then that isn't our problem.' Source-centric, I know. But it's just the way it is. The RPM distribution can get away with the copy over the symlink thanks to the version information being stored in the rpm database. But, no, this isn't necessarily an RPM issue per se -- it is a general library versioning issue. James, you can simply symlink libpq.so.2.0 to libpq.so.2.1 to get your stuff running. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
James Hall wrote: > >James, you can simply symlink libpq.so.2.0 to libpq.so.2.1 to get your > >stuff running. > That's exactly what I did and everything runs great now! > Thank you very much (Trond, Lamar) for all your help and 2 great products! Glad to help! And you're welcome. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
[cc: list changed -- GENERAL bcc'd, PORTS cc'd]
Peter Eisentraut wrote:
> Lamar Owen writes:
> > I think that by packaging the RPM's to include libpq.so.2.x as simply
> > libpq.so.2 (as long as 2.x's are link-compatible), I can help alleviate
> > this problem for future builds.
> The symlink order will not be changed, other improvements are
> welcome.
I'm not asking for a change in the core tarball.
I could say more, but I've said it elsewhere, and it really doesn't
deserve repeating, as the decision to continue library versioning in the
core tarball has been made, and I'm not going to question that decision
here.
The changes I am likely to make, barring good technical reasons to not
do so are:
1.) For RedHat 6.x RPM's (as well as RPM's for other distributions that
originally shipped PostgreSQL 6.5.x or 6.4.x), ship a symlink to
libpq.so.2.1 for libpq.so.2.0;
2.) For all RPM's, change the symlinks to be:
libpq.so -> libpq.so.2
libpq.so.2 is the library itself
libpq.so.2.x -> libpq.so.2 (so as to not break compatibility)
No changes are contemplated for libpq.so.1 compatibility -- there are
differences there -- but, of course, if sound technical reasons are
found to do so, I can deal with that as well.
I just want to make it easier to deal with our RPM's, that's all. But,
as always, I am open to technical suggestions.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11