[nSLUG] Chapter Three - Some HP Installation Progress.

robert ashley at chebucto.ca
Wed May 11 14:53:15 ADT 2005

On Wed, 2005-11-05 at 12:50 -0300, Bill Davidson wrote: 
> Hi:
> On Wed, 2005-11-05 at 11:54 -0300, robert wrote:
> > If I understand Jack correctly, libjep.so.62 first looked like a missing
> > library. Then we found this missing library. So, is this library NOT
> > missing, but rather just not linked properly? 
> Hmm, re-reading what I wrote that you quoted I suddenly realize how
> confusing it is.  One of the problems is that the word "link" maps to
> several different meanings.  Well, two.  First is a file link (which,
> annoyingly, can be either a hard link or a soft link, but we'll deal
> with that another time).  A file link is, essentially, another name for
> a file.  So, for example, if I create a file in my home directory called
> "foo", I can issue the command "ln foo bar", and now a listing (ls)
> shows two files in my directory, one called "foo" and one called "bar",
> both the same size.  But there is really only one file, with two
> directory entries.  If I edit "foo" I will see the changes in "bar".  If
> I delete "foo", "bar" will still be there, only the directory entry for
> "foo" is gone.
> Now consider libjpeg.so.  You actually install libjpeg.so.major.minor,
> and so you can have more than one version of the library present on your
> system without conflict.  In this case you have libjpeg.so.62.0.0.
> Actually, this is dreadfully misnamed -- there have not been 61 previous
> major versions of libjpeg.  It should be called libjpeg.so.6.2.0,
> meaning the major version is 6, the minor version is 2, and the "tiny"
> subversion is 0, but the "62" thing seems widespread.
> Anyway, then you have a link called libjpeg.so.62, which really should
> be libjpeg.so.6 (or libwhatever.so.major).  This is just another name
> for the same file.  Then, finally, you should have another link called
> libjpeg.so which is just another name for same file.  As you can see,
> in /usr/lib you might have libjpeg.so.62.0.0, libjpeg.so.62.0.1,
> libjpeg.so.61.0.0, libjpeg.so.5.3.1, etc.  The first link tells us that
> at runtime when we need libjpeg.62 we use libjpeg.so.62.0.0.  The last
> link tells us that at compile time, when we need to link (see below)
> against the jpeg library, we use libjpeg.so.62.0.0.
> So what do I mean by that last use of the word "link" above?  Well, what
> is libjpeg.so?  It is a dynamic library of code, functions and data
> structures that let a programmer manipulate jpeg files easily.  To use
> those structures and functions first you need to include in your code
> references to some files that describe those functions and structures.
> Then your compiler can compile your code to an object file.  This file
> contains a machine code version of your code that references functions
> that are located elsewhere -- in library files.  So then you need to
> "link" your code against all its external libs, which means it reads
> those library files and does some magic (notice me waving arms madly at
> this point) to make the executable that it spits out be able to use the
> functions in those libs at runtime.  Then, when you run the program the
> loader, or run-time linker (note 3rd use of "link" here) actually loads
> the libraries into memory (unless they already are in memory) and fixes
> the references in the program to point to the right memory locations.
> So you have "ln" which is the program that creates file links.  And you
> have "ld" which is the linker.  And you have "ld-linux.so" (or just
> "ld.so" in older implementations) which is the runtime linker/loader.
> When you tell the compiler or linker (the compiler is smart enough to
> call the linker with all the right flags when you need it to) to use
> libjpeg (with -ljpeg) it looks for the file (actually link) called
> libjpeg.so.  I think Debian only creates that link if the "-dev" package
> for a given library is installed, which installs the header files as
> well.  The program "ldconfig" will create the right links in places
> like /usr/lib (see "man ldconfig" and /etc/ld.so.conf), but of course
> those are of limited utility if the header files aren't in place.
> I hope that clarifies things a tiny bit, or at least confuses you in new
> and interesting ways...
> > Could you specify the directory environment and the options/arguments
> > for the ldconfig command?
> No, that's what "man" is for.

Well, the man terminology on is still pretty dense and mystifying. So I
tried a bunch of things...

usr/bin# ldconfig libjpeg.so
ldconfig: relative path 'libjpeg.so' used to build cache

usr/bin# ldconfig libjpeg.so.62
ldconfig: relative path 'libjpeg.so.62 used to build cache

usr/bin# ldconfig libjpeg.so.62.0.0
ldconfig: relative path 'libjpeg.so.62.0.0 used to build cache

Then I tried the libjeg.a assuming I didn't have it, just see what

usr/bin# ldconfig libjpeg.a
ldconfig: relative path 'libjpeg.a used to build cache

Whoops! How can that be? Tried a fictitious file...

usr/bin# ldconfig libjpeg.63 [Fictitious]
ldconfig: relative path 'libjpeg.63 used to build cache

This confirms for me that I'm not using ldconfig correctly. This is no

The examples in man are confounding to me.

# /sbin/ldconfig -v 
       will  set  up the correct links for the shared binaries and rebuild the
# /sbin/ldconfig -n /lib
       as root after the installation of a new shared  library  will  properly
       update the shared library symbolic links in /lib.

So I tried

# /sbin/ldconfig -v
which renders a million lines of lib files 
Is this showing the links ldconfig is making? 


# /sbin/ldconfig -n /lib

which renders nothing


# ldconfig /sbin

which renders nothing --> saw this one on


# /usr/lib/ldconfig -v
bash: /usr/lib/ldconfig: No such file or directory

Then I aped and adjusted a similar version found via Google

# ldconfig -v | grep libjpeg
libjpeg.so.62 -> libjpeg.so.62.0.0

Hey! This looks like maybe it friendly to your explanation, Bill?
Does this mean ldconfig made a link between the two 'ln' libjpeg files?

Perhaps this should suffice to show that I'm failing to understand the
mechanics of the ldconfig program. I think I've got a vague idea of your
theoretical explanation, thanks for that. But it's not translating into
the pragmatics of the actual steps I need to execute. The man page on
ldconfig presumes a fundamental grasp with the principles it rests on.

But maybe with all this trial and error jabbing, the last shot is what
you had in mind? 

# ldconfig -v | grep libjpeg
libjpeg.so.62 -> libjpeg.so.62.0.0




More information about the nSLUG mailing list