RPM error with PGP 6.5.8 installation

Rick Stevens rstevens at vitalstream.com
Thu Sep 29 17:48:17 UTC 2005


On Thu, 2005-09-29 at 10:15 -0400, FS wrote:
(snipping off some old stuff we really don't need now)

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

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

No, you have to compile the source code to tell the compiler and linker
to go grab the static libraries and stick the necessary bits into the
executable.  If you have a binary that's been built to use shared
libraries, you can't convert it to use static and vice versa.

An executable that's built to use shared libraries (.so) does NOT
contain any library code.  The libraries needed are loaded when the
executable is run.  The "ld" program dynamically links the program's
needs against the various libraries.  Also note that only ONE copy of
any given library is loaded into the system at any given time,
regardless of how many programs use it.  There is a small section of
memory that is unique to each instance of the library's use, but the
library _code_ is only loaded once.

On the flip side, a program built to use static libraries (.a) has a
copy of the library in the program itself.  Those programs don't need
the libraries at all after they've been compiled and linked.  They're
sometimes called "stand alone", and you'll find that many of the
programs in the /bin or /sbin directory are built this way as they're
needed during the bootup process of Linux when /usr/lib or /lib may
not be available yet because they're on other filesystems.

The downsides to static programs are that they're much bigger and
have a much bigger memory footprint.  The upside is that they start up
much faster since "ld" doesn't have to load the libraries needed and
resolve the links.

A good example of static versus dynamic is Apache.  For heavily loaded
servers, we recommend building Apache with statically linked PHP and/or
Perl modules rather than building to use dynamic modules.  Yes, Apache
is much bigger, but when you need to spawn tons of copies of Apache to
cover web hits, the decrease in startup time for each copy more than
makes up for the cost of the memory footprint.

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

You can give gcc the "-static" option.  Most Makefiles have a variable
called "CFLAGS" and you should be able to put it in there.  Be aware,
however, that not all libraries are available in both forms (static and
dynamic), so you may end up trying to link against a non-existent
library and getting a linker error.

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

If it's static, its kinda irrelevant as the executable has all the
library code it needs built in.  You can use the "nm" command to see
what symbols are involved.  See "man nm" for more details.

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

Some are stand-alone, others require other libraries to function.  For
example, the standard C math library, libm, really needs the standard C
library (libc) to be effective.  It's not a true dependency, but you
need libc to make libm work.

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

You really need to get familiar with things like the C language.
Regardless of what others may say, the lowest common denominator in most
Unix/Linux programming is C (C++/C# all eventually deconvolve to C).
The vast majority of Unix/Linux is written in C (certain, highly
optimized parts of the kernel are in assembly), so an understanding of
how C works will give you an insight into the system's basic operation.

Then you need to read up on the Gnu C system (gcc, gpp or g++, as, ld)
to see how it works with libraries, executables, object files, etc.
There are very good docs on that at the Gnu website
(http://www.gnu.org/manual/manual.html is a good starting point).

Mostly, you'll find that enrolling in UHK (University of Hard Knocks)
for a few semesters is what teaches you the most.  By "UHK", I mean
rolling up your sleeves, writing code, compiling it and sorting out
the inevitable errors.  It's like roller skating.  I can't really tell
you how to do it...you gotta go out and skin your knees just like the
rest of us.  When you get stuck, ask for help.

It's not really all that scary.  There's a lot involved, but once the
first little bit of it reveals itself to you, the rest comes fairly
easily, you'll see how they all interrelate, and you'll be able to start
to predict what happens next or be able to see where you went wrong.
Trust me, it's gonna be OK!

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

No worries, Faisal.

----------------------------------------------------------------------
- Rick Stevens, Senior Systems Engineer     rstevens at vitalstream.com -
- VitalStream, Inc.                       http://www.vitalstream.com -
-                                                                    -
-              Careful!  Ugly strikes 9 out of 10 people!            -
----------------------------------------------------------------------




More information about the Redhat-install-list mailing list