Rod Evans wrote:
Thanks Rod for the insight. Looks like I'll have to, via trial and
error, eliminate unreferenced so's. Let's hope they don't change that
much between releases. :)
-- Jim C
> Jonathan Adams wrote:
>
>>> So would it be reasonable to assume that so's that don't have the
>>> version suffix might be dlopen candidates? Maybe I'll just exclude
>>> them from the removal algorithm?
>
> I don't think you can infer much from a name.
>
> Our founding fathers had a design. Shared objects would have major
> numbers (ie. libfoo.so.1), and symlinks would be established to these
> (ie. libfoo.so -> libfoo.so.1), so the developers could reference
> these dependencies at compiler time using the -l notation (ie. -lfoo).
>
> A shared object that can be specified as a dependency (as created when
> using -l), is no different from a shared object that can be dlopen'ed.
> Some applications might have dependencies on libfoo.so.1, others might
> wish to dlopen("libfoo.so.1").
>
> The conventions have gotten very lax. We have shared objects that
> are only delivered as "*.so". Shared objects that are only delivered
> as "*.so.?". Both. Or even various incantations of "*.so.1.23.65.99".
>
> I fear that whatever naming algorithm you use, you'll leave some
> objects behind that could be deleted, and delete some that are still
> required :-(
>
