RPM error with PGP 6.5.8 installation

FS bastiji at gmail.com
Thu Sep 29 14:15:45 UTC 2005


On 9/27/05, Rick Stevens <rstevens at vitalstream.com> wrote:
> On Tue, 2005-09-27 at 18:10 -0400, FS wrote:
> > On 9/27/05, Rick Stevens <rstevens at vitalstream.com> wrote:
> > > On Tue, 2005-09-27 at 16:05 -0400, FS wrote:
> > > > On 9/26/05, Rick Stevens <rstevens at vitalstream.com> wrote:
> > > > > On Mon, 2005-09-26 at 15:10 -0400, FS wrote:
> > > > > > [Cross posted to Fedora list]
> > > > > >
> > > > > > Hello all,
> > > > > >
> > > > > > While trying to install PGP 6.5.8 cmd line RPM (downloaded from
> > > > > > http://www.pgpi.org/products/pgp/versions/freeware/unix/6.5.8/) , I'm
> > > > > > getting the following error:
> > > > > >
> > > > > > root at c7504s98 /usr/local/downloads/PGP$ rpm -Uvh
> > > > > > PGPcmdln_6.5.8_Lnx_FW.rpm
> > > > > > error: Failed dependencies:
> > > > > >         libstdc++.so.2.8 is needed by pgp-6.5.8-rsaref658
> > > > > >
> > > > > > I googled on this and found some tips to ln -s the current version
> > > > > > (libstdc++.so.5.0.5) to libstdc++.so.2.8 but that doesn't work too.
> > > > >
> > > > > Did they also tell you to rerun ldconfig after making the link?
> > > > >
> > > > > > I'm not too sure what the lib files are used for, but it seems that
> > > > > > the 5.0.5 would be newer than the 2.8.
> > > > > >
> > > > > > Any help/tips/pointers appreciated!
> > > > >
> > > > > The package you got was designed the older library.  That's what it's
> > > > > linked against so you have to satisfy it somehow.  There's two ways to
> > > > > do that:
> > > > >
> > > > > Set up the symlink as the google search told you, and run "ldconfig -v"
> > > > > so the linker knows about it.  This may satisfy rpm.
> > > > >
> > > > > Force the RPM to load via "rpm -ivh --force --nodeps".  I don't
> > > > > recommend that.  The RPMwill install, but it may not work properly.
> > > > >
> > > > > If you insist on keeping that C library, then I'd REALLY suggest you
> > > > > download the source RPM and rebuild it.
> > >
> > > > Thanks for the response Rick.
> > > >
> > > > Trying both ways didn't work. When I force the RPM to install and then
> > > > try to run PGP it gives an error
> > > >
> > > > pgp: relocation error: pgp: undefined symbol: __eh_pc
> > >
> > > I was concerned about that.  One worries when you have to do a "--force"
> > > or "--nodeps" on an RPM install.
> > >
> > > The version of PGP you got was built for a different library set and it
> > > doesn't surprise me one iota that it wouldn't work.
> > >
> > > > Downloaded the source from the pgpi site and tried to run the build.sh
> > > > from there and it also gave me a spectacular multi-line error and then
> > > > quit. Error shown was:
> > > >
> > > > g++ -g -O2 -g  main.o args.o pgp.o getopt.o fileio.o config.o
> > > > doencode.o dodecode.o lists.o keyview.o keygen.o keyadd.o keyremove.o
> > > > keyedit.o keyexport.o keymaint.o keysign.o keyrevoke.o more.o groups.o
> > > > match.o misc.o pgpAcquireEntropy.o pgpLanguage.o
> > > > ../shared/pgpDiskWiper.o ../shared/pgpClientErrors.o -o pgp
> > > > -L/usr/local/lib -L../../../libs/pfl -L../../../libs/pgpcdk/unix
> > > > -L/lib/linux -lPGPui -lPGPsdkNetwork -lPGPsdk -lpfl -lpthread  -lm
> > > > -lnsl
> > > > /usr/bin/ld: cannot find -lPGPui
> > > > collect2: ld returned 1 exit status
> > > > make: *** [pgp] Error 1
> > >
> > > The problem you describe above is a missing library...libPGPui.so  I
> > > don't think its available in an RPM for FC1.  You'd need to get the
> > > source for that and build it first, THEN build PGP.  You're manually
> > > satisfying the dependencies now.
> > >
> > > > So for now, as someone suggested in the Fedora list, the option is to
> > > > run GPG and hope that it really is as compatible as everyone says it
> > > > is.
> > >
> > > GPG is VERY compatible, integrated well into the system and, as a
> > > result, a LOT easier to manage.  I use GPG almost exclusively.
> > >
>
> > Rick -- Thanks for the informative answer. I gotta ask you this! How
> > in the world is one supposed to know about all these dependencies and
> > missing libraries with names sounding like the martians have invaded
> > and started renaming files...
>
> Well, first off, make sure you read the README and INSTALL files that
> come with most tarballs.  They generally tell you what the requirements
> are for the programs you build.  As to the alphabet soup, remember that
> all libraries start with "lib" and end with ".so" or ".so.somenumber"
> or ".a".  The vast majority live in the /usr/lib directory tree, but
> a number of really core libraries live in /lib instead.
>
> > What would you recommend as a starting point to understand all the
> > libraries, their function, and how they all fit in the big picture as
> > far as Linux goes?
>
> There really isn't a simple answer to that, sorry to say.  Libraries
> are, well, libraries!  There's a lot of them because each has certain
> things they bring to the table that others don't and the idea is not
> to bloat a library with stuff you may not need.
>
> Once, long ago (well, 1979 or there abouts), there was a move afoot to
> put everything you needed to support the C language into a single
> library.  The problem was, the library was HUGE!  The VAX/VMS linker
> couldn't even deal with it (and VAX/VMS was the mac-daddy of all OSes
> back then).  So, the stuff you really used a lot (string handling, I/O,
> etc.) got stuck into the "main" library, and esoteric stuff (floating
> point math, trig functions, you get the idea) was stuffed into
> "auxiliary" libraries.  The main library has come to be called "clib" or
> "libc".  The other have other names.
>
> The one you ran into is a GUI library for PGP, "libPGPui" or "library
> for PGP user interfaces".  It is required for PGP stuff that uses a
> graphical user interface.  It's not required if you use just the command
> line parts of PGP.
>
> As to what you need to get something going...generally, if you go to a
> site and look at the downloads, most people package things into
> libraries (or support tarballs) and executable tarballs.  The
> executables ALWAYS depend on the libraries or support things.  pgpi
> isn't set up that way, much to their detriment.
>
> You've run into one of the problems with open source...there really
> isn't a standard that people MUST adhere to.  There are guidelines and
> recommendations, but you can't compel people to comply beyond sticking
> with the Gnu General Public License or OSF's "copyleft" rules.
>
> Generally, you build the package.  If you get an error message, you try
> to decipher it and resolve the problem.  If that confuses you, you do
> what you did and you ask for help!  Nothing wrong with that...we've all
> been there, done that and have the T-shirt and baseball cap to go along
> with it.  That's one reason people such as myself and many, many others
> contribute to these lists...we've been there and we want to help prevent
> others from having to walk around the forest blindly as we once did.
>
> > Thanks as always for your help Rick!
>
> Just "paying it forward", Faisal.  One day, you'll contribute to a list
> as well and someone will be in your debt.  That's the way this thing
> works!
>
> ----------------------------------------------------------------------
> - Rick Stevens, Senior Systems Engineer     rstevens at vitalstream.com -
> - VitalStream, Inc.                       http://www.vitalstream.com -
> -                                                                    -
> -    I don't suffer from insanity...I enjoy every minute of it!      -
> ----------------------------------------------------------------------
>
>

Thank you Rick. A few follow-up questions if you will.

- Is it possible to build a binary without using the libraries
(knowing which libraries it would use and having the binary in hand),
without having the source code? My guess is no, but doesn't hurt to
ask...

- Is it possible to build it statically with the source cocde, but
without breaking the installer shell that generally is accompanied by
the source? If so, how/what do I change to make that happen?

- How does one find out as to which library is being used by an
executable, or if it's statically built?

- Do the libraries in turn depend on other libraries too or are they
all a world of their own?

- There's gotta be some place I can start trying to learn this
dependency/building/trying-to-sort-out-what-goes-where kinda stuff on
the web. Do you have any recommendations for that?

As always, your support and very kind mannerism is appreciated.

Regards,
Faisal




More information about the Redhat-install-list mailing list