Re: php and pgsql and rpm/compile - Mailing list pgsql-general

I understand what you are saying, but for arguments sake, I would assume
that the libpq.so files were "backward compatable".  That if you had an app
requiring libpq.so.1 and you linked it to libpq.so.2, that it would work
because  it would support calls to previous versions.  Am I making a poor
assumtion? (That is the reason I tried the symlink... I assumed that it
would be ok to "fool" the application).

As for installing with --nodeps, I would say I don't know the full
implications, but since I only had one dependency out of whack (that I knew
I had) I decided to "chance it".  Again, another poor assumption?

Finally, thanks for explaining how some of the rpm and ld.so works.  It
helps.  It's amazing how much easier computing is (for advanced users at
least) when you learn how the actual operating system works... A friend of
mine yells at me for not using Xwindows and gui tools more... tell him I
have to stick to command line... I'm learning too much this way. :)

Adam Lang
Systems Engineer
Rutgers Casualty Insurance Company
----- Original Message -----
From: "Lamar Owen" <lamar.owen@wgcr.org>
To: "Adam Lang" <aalang@rutgersinsurance.com>
Cc: "PGSQL General" <pgsql-general@postgresql.org>
Sent: Thursday, September 07, 2000 3:24 PM
Subject: Re: [GENERAL] php and pgsql and rpm/compile


> Adam Lang wrote:
>
> > It actually runs without the symlink and --nodeps
>
> The reason it runs but won't install is due to the way the RPM build
> process follows symlinks versus the way ld.so treats symlinks.  The
> actual linked file is simply libpq.so -- but the RPM findrequires script
> (which you can look at yourself in /usr/lib/rpm) resolves the symlink
> and places the dependency on the actual lib -- in this case,
> libpq.so.2.0. It does this for versioning, as ld.so is version-agnostic.
>
> Well, since libpq.so.2.1 is not that different from 2.0, it works fine
> -- however, if you had an app linked against libpq.so.1.0 (which would
> be true if you used a binary RPMset from RedHat 5.x contribs that linked
> against the RH 5 PostgreSQL 6.3.2), then you might run into some
> mysterious problems as libpq.so.2.1 is dynalinked into an app that is
> expecting libpq.so.1.0.  Or worse yet, you could use an app linked
> against Postgres95 1.01's libpq.so (which is STILL libpq.so as far as
> ld.so is concerned) -- and then you are guaranteed to have problems
> (been there, done that).
>
> The ld.so linker, of course, doesn't care -- it just loads libpq.so in
> the LD_PATH and goes on with its life.  That's why RPM enforces
> dependencies -- and why there is a --nodeps switch for when you need it
> -- as long as you are prepared to deal with the potential
> incompatibilities.
>
> Of course, in this particular instance it works due to the low mismatch
> from 2.0 to 2.1 libpq.
>
> --
> Lamar Owen
> WGCR Internet Radio
> 1 Peter 4:11