[nSLUG] Chapter Three - Some HP Installation Progress.
bdavidso at supercity.ns.ca
Wed May 11 12:50:23 ADT 2005
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.
> Sheeeesh, I ask a lot of questions, eh?
Yes, but that's a good thing.
bdavidso at supercity.ns.ca
More information about the nSLUG