Re: Versioned Symbols
On Fri, 07 Mar 2003, Wichert Akkerman wrote:
> Previously Stephen Frost wrote:
> > We need to make a decision on how to properly handle multiple library
> > versions ending up linked into the same process.
>
> I think what we should do is simple: 'do not do that'.
We have been very bad on that regard. Certain... not-so-nice measures would
have to be taken to keep up with the 'do not do that' solution.
I consider that non-workable for core libraries (SASL, LDAP, glibc/nss
modules, libX* and unfortunately, part of the kde and gnome bloat).
As an example: for SASL (which currently causes breakage encompassing LDAP
(and through it, glibc nss modules), we would have to force-feed upstream a
SASL2 enabled source of postfix and sendmail, for example. We would also
have to drop our old openldap 2.0 and somehow get 2.1 ready.
> > - Implement versioned symbols
> > - May cause binary compatibility issues
> > - Doesn't follow LSB (I believe..)
> > - Could be difficult to do correctly
After we fix the @#$^#@^$ cretin problems with the dynamic loader adding
static crap to libraries in certain archs [that must not be versioned], it
is actually trivial to do correctly, GIVEN a proper build environment (i.e.
not massively braindamaged makefiles, etc).
> Very hard to implement and will result in non-trivial patches that
> upstream sources will probably never merge.
Indeed. But it is actually useful for Solaris as well, so you might find
some of upstream quite willing to take the patches. We already do so for
libdb, and upstream for libsasl already said they would accept patches that
did it right. It is difficult to know how many would be willing, if there
is a hard enough shove (with ready-to-apply patches, obviously).
> > - Conflict between library versions
> > - Wouldn't allow valid setups where the versions aren't linked into
> > the same process
> > - Lots of packages would end up uninstallable for certain library
> > upgrades
>
> Those two reasons make it obvious we should not do that I think.
It is actually not doable. Libraries conflict only inside a process boundary
(unless they have been extremely badly designed and have an external
dependency on a file or something like that), so we must allow conflicting
libraries installed in the system.
> I challenge you to implement it for a few versions of a few different
> non-trivial libraries.
We just need it for libraries that are themselves linked by other
libraries, and that change too much. E.g. libz doesn't need it (thank
god!), but SASL and openldap most definately do, and glibc and libdb already
have it.
> I think a different solution: check for this problem when build a
> package and abort if you hit it. That is trivial to implement as
Won't work 100% of the time. dlopen makes this also a runtime problem.
> a linda check or standalone tool you can call from debian/rules. In
> fact I think dpkg-scanlibs already does that.
Well, either linda or lintian is indeed trapping illegal linkage of two
different versions of libraries in the same binary. But this catches only
a part of the problem, and the easy one to fix, at that :(
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
Reply to: