Re: Neat gtk/gdk-imlib pain
Gordon Matzigkeit <gord@trick.fig.org> writes:
> Hi!
>
> >>>>> Jim Pick writes:
>
> >> Erm, but that doesn't make any sense in the context of glibc!
> >> glibc2.1 is NOT a unique soname but is simply a glibc2.0 with
> >> changes. Somehow the symbol versioning is used to tell '2.1
> >> special' programs apart from '2.0 special' programs and 'do the
> >> right thing' You don't need to have two libcs.
>
> JP> I believe that's the purpose for it in glibc. But it's a generic
> JP> facility that might be useful in other areas (like what I'm
> JP> suggesting).
>
> Symbol versioning is finer-grained than sonames (i.e. if you change
> the soname, you break symbol versioning).
If you've got symbol X (1.1) in library A, and symbol X (1.2) in
library B - you shouldn't have the situation where a reference to X
(1.1) gets resolved to X (1.2) in library B - even when both libraries
are examined by ld.so.
The current situation is that we've got symbol X in library A and the
same symbol X in library B. Both libraries get pulled in by ld.so,
and it's somewhat random which piece of code is actually bound.
I guess your point is that symbol versioning allows you to make
incompatible changes to the API without changing the soname (which
would fix our probably as well).
> Regardless of whether we have it or not, we still need a way to fix
> inter-library dependency graphs that depend on conflicting sonames.
Hmm. The problem is that when we are building a package, we have no
idea what libraries it will eventually be dynamically linked with.
At run time, ld.so has no clue that any two (or more) of the object
files that it is pulling in are going to be incompatible. Adding
checks would probably incur a performance penalty - and what would it
do if the situation arises? Probably just fail.
Perhaps the check could be incorporated at package install time. The
package manager (eg. dpkg) would have to maintain a database of
library dependencies - and prevent the installation of combinations of
packages that would mess up the dynamic linker.
Essentially, dpkg could be extended to add the equivalent of a
"Conflicts" to the packages it is about to install. These automatic
"Conflicts" would be calculated based on what other packages were
installed on the system at runtime.
It would be a big job though - dpkg would need intimate knowledge of
the workings of the dynamic linker - and would need to track the
inter-library dependency graphs for all the libraries and binaries.
It might also screw up apt, which would need to understand a whole new
set of dependencies.
Cheers,
- Jim
Reply to: