Re: 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(dot)Hall(at)RadioShack(dot)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.

Trond Eivind Glomsrød wrote:
> James Hall <James(dot)Hall(at)RadioShack(dot)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(dot)owen(at)wgcr(dot)org> writes:

> Trond Eivind Glomsrød wrote:
> > James Hall <James(dot)Hall(at)RadioShack(dot)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(dot)owen(at)wgcr(dot)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(dot)owen(at)wgcr(dot)org> writes:

> Trond Eivind Glomsrød wrote:
> > Lamar Owen <lamar(dot)owen(at)wgcr(dot)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(dot)owen(at)wgcr(dot)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(at)gmx(dot)net http://yi.org/peter-e/

[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

Lamar Owen writes:

> 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.

(If you're arguing against versions in shared libraries you're up against
much higher powers than PostgreSQL.)

I've found the problem. Trond was right, it was the fact that the
programs are linked against libpq.so.2.1, not libpq.so.2. And I was
right, too :-), in that it was the -soname switch, which essentially seems
to say "If you link with me, record that fact that I'm really <soname>."

If you want to fix this in the RPMs, do something along the following
lines (manually simulated patch) in Makefile.shlib:

ifeq ($(PORTNAME), linux)
install-shlib-dep := install-shlib
shlib := lib$(NAME)$(DLSUFFIX).$(SO_MAJOR_VERSION).$(SO_MINOR_VERSION)
- LDFLAGS_SL := -Bdynamic -shared -soname $(shlib)
+ LDFLAGS_SL := -Bdynamic -shared -soname lib$(NAME)$(DLSUFFIX).$(SO_MAJOR_VERSION)
LDFLAGS_ODBC := -Bsymbolic -lc -lm
SHLIB_LINK += -lc
CFLAGS += $(CFLAGS_SL)
endif

Apps linked against the old libraries will not be fixed until relinked.

--
Peter Eisentraut peter_e(at)gmx(dot)net http://yi.org/peter-e/

Peter Eisentraut wrote:
> I've found the problem. Trond was right, it was the fact that the
> programs are linked against libpq.so.2.1, not libpq.so.2. And I was
> right, too :-), in that it was the -soname switch, which essentially seems
> to say "If you link with me, record that fact that I'm really <soname>."

There are two problems here, not just the one. This is the one
problem. The other is that _existing_ RPM packaged apps still need
support -- even though they were linked against the full soname.

> If you want to fix this in the RPMs, do something along the following
> lines (manually simulated patch) in Makefile.shlib:

That is useful information. Thanks.

> Apps linked against the old libraries will not be fixed until relinked.

Or until the RPM's supply 'stop-gap' symlinks to help existing packages.

I'll implement both, as they solve two sides of the same problem.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11