"Kevin Coffman" <[EMAIL PROTECTED]> writes: > Getting back to this. I'm curious if there is a specific reason why > the *.so symlink was not there? Adding the ".0" shouldn't be > necessary. But there may be a reason for not including the .so > symlink that I am not aware of. > > My default install in /usr/local/lib shows: > > lrwxrwxrwx 1 root root 29 2008-07-30 16:59 > /usr/local/lib/libnfsidmap_nsswitch.so -> libnfsidmap_nsswitch.so.0.0.0 > lrwxrwxrwx 1 root root 29 2008-07-30 16:59 > /usr/local/lib/libnfsidmap_nsswitch.so.0 -> libnfsidmap_nsswitch.so.0.0.0 > -rwxr-xr-x 1 root root 17141 2008-07-30 16:59 > /usr/local/lib/libnfsidmap_nsswitch.so.0.0.0
This looks like a reasonable result from "make install" in a regular autotooled source distribution. The libfoo.so link is used by the linker to find the library based on the -lfoo switch. The object resulting from the link will refer to libfoo.so.X and then that will be a symlink to libfoo.so.X.Y.Z. So far, so good. With typical libraries on Debian, libfoo.so will be provided, along with the required headers, by libfoo-dev (or perhaps libfooX-dev, depending on how it has been packaged). libfoo.so.X and libfoo.so.X.Y.Z will be in the libfooX package (or perhaps libfoo, if X has never changed), and applications linked to libfoo will depend on that package, as will libfoo-dev. Of course, the shared objects we're talking about are not regular libraries and so should be handled specially. This could mean altering the dlopen calls as per my suggestion, or overriding the autotools stuff and installing them as libnfsidmap_foo.so somewhere or other. -- Paul Collins Wellington, New Zealand Dag vijandelijk luchtschip de huismeester is dood -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
