question on linking process
 

ive been studying the dynamic linking process whereby a shared objected "libfoo-2.5.so" is linked with "libfoo.so.2" for dynamic linking during execution and then "libfoo.so.2" is linked by "libfoo.so" for the ability to link right after compile with the "ld" command.
i understand ldconfig updates the links for each lib by checking if theres a newer version in /lib & /usr/lib. for example "libfoo.so.2" now points to a newer "libfoo-2.6.so" instead of "libfoo-2.5.so". When theres a major library version change a from "libfoo-2.6.so" to "libfoo-3.1.so" a new soname link is created called "libfoo.so.3" and the old "libfoo.so.2" still exists. What happens with the "libfoo.so" that points to libfoo.so.2 during the major version # update. is it linked to the newer "libfoo.so.3" or does it stay the same???

Also in my /lib dir on slackware the "libfoo-2.5.so" type libs and "libfoo.2.so" links exist but no "libfoo.so" links exist. is this for security and space concerns on the root partition?? where do they exist? my /usr/lib dir does have them for its libs.

Hi
 

Well, You confused me a little. Actually I'm not sure what your asking, so I'll explain what I know about libraries.

The path's to the library directory that linux is aware of are held in /etc/ld.so.conf. If the path isn't there for wherever your libraries are, linux ain't gonna know when you do a /sbin/ldconfig.

The linking of libraries or whatever via: ln -s /usr/X11/lib.so.CaptainsLog123455CVS89.3 /usr/X11/lib.so.1

is just like so.

If you are sharing libraries, it just grabs the library it needs from the paths you put into ld.so.conf. Whether it's smybolically linked or static. It'll just use the library. Shared is supposed to save space on your hard drive. Static is not. Although the drawback is that your shared libraries sure as hell better work or else everything is done broke. Whereas if you have static libraries to an application, if they are broke then just one app is broke.

Parts is parts. I hope that answers a little of your question.

Thor

when you enter a command like "$ gcc -lmilt prog.o", the linker ld searches for "libmilt.so" in ld's search directories. configured at ld's compile time i believe.
"libmilt.so" -> "libmilt.so.2" -> "libmilt-2.6.so" the 2nd link is used for dynamic linking at runtime.

what happens to "libmilt.so" when "libmilt-3.1.so" is added to the system.

i know ldconfig will add a new link "libmilt.so.3" when it scans for new and updated libs.

but what does "libmilt.so" now point to. the new "libmilt.so.3" or the original "libmilt.so.2"

im guessing the new "libmilt.so.3"

is this any clearer than my original post??

Yes, it will relink libmilt.so to point to the most recent version (libmilt.so.3) when ldconfig is run.

the book im reading "linux programmers reference 2nd edit." tells me the "libfoo.so" links used for initial compiling have to be manually created and are not updated by the ldconfig utility which just creates links for runtime dynamic linking. this is proven by the last sentence above. what does the job of creating those "libfoo.so" links to "libfoo.2.so" so a command like "$ gcc -lfoo prog.o" can find them??? what happens to "libfoo.so" when a new link "libfoo.3.so" is created along with the original "libfoo.2.so" link. ldconfig seems to have nothing to do with creating "libfoo.so" type links.

also the default scan directories for ldconfig are /lib & /usr/lib.
on my slackware installation /lib doesnt include any of the libfoo.so type links, but /usr/lib does. why is this?? this is more proof that ldconfig has nothing to do with creating the "libfoo.so" type links.

it turns out the slackware pkg management allows a script to be run after files are installed for a package. this optional script does the work of updating the "libfoo.so" and "libfoo.2.so" links. so it is done manually on a per package basis behind my back. also if there's a major version # change for libraries and the 2 are incompatible, it seems the name is changed. clearing up the issue of what "libfoo.so" points to. for example libfoo.so.1 is changed to libfoo-2.so.1. so a new "libfoo-2.so" is created. it seems the updating scheme for each different library isnt always consistent. i guess that's what u get when you have development anarchy and no global control. freedom has a price. i think this has cleared everything up for me.

one last question. when a library is updated from "libfoo.so.2.1" to "libfoo.so.3.1". is "libfoo.so.3.1" backward compatible with "libfoo.so.2.1"??? it seems under the logic i described earlier it is.