On Mon, 9 Apr 2007, Rex Dieter wrote:
Mark Crispin wrote:
My experience with the modifications made by others to support shared
libraries has been unrelentingly negative.
On the contrary, our experiences of distributing shared libraries of
libc-client in Fedora has been (almost) nothing but positive.
ymmv, of course...
Indeed, mileage does vary. :-) I have spent many hours investigating
problems that turned out to be due to shared library skew. It's the UNIX
world's equivalent of Windows' "DLL hell".
For example, I get a bug report about some issue that was fixed a while
back, yet the user seems to be running the version with the fixed code.
Strangely, the unmodified UW distribution works even though "no changes
were done in that code." Sure enough, it was lunk to use c-client as a
shared library and picked up an older version.
It is axiomatic that, whether shared or static library, the .h files used
to build an application for a library should correspond to the library.
I've seen cases where shared libraries did not correspond to the .h files;
generally this is when the shared library was placed in one RPM and the .h
files were placed in a separate "development" RPM. Although the same
problem is possible with static libraries, I haven't seen it occur.
Even more common is the possibility of a binary that was built with one .h
file set used with a different version of the shared library. I have
never tried to maintain this level of binary compatibility. There is a
versioning mechanism for shared libraries, but I have not seen the third
party distributions of c-client shared libraries increment their version
when skews occur.
Given these problems with third-party distributions, I've been quite
reluctant to step into that swamp myself. The modest cost of each
application having its own copy of c-client is IMHO well worth the savings
brought about by having the certain knowledge that the application was
built for the version of the c-client library that it uses.
It should be noted that the cost IS modest, and is only incurred per
application (NOT per running process) and per binary file on the disk.
Each running imapd shares its code segment with other running imapds. If
you have only one c-client based application (imapd, Pine, PHP, etc.) on
your system, then you save NOTHING by having c-client be a shared library.
That cost is plummeting. Even if you have several c-client based
applications installed on your system, the disk space cost for using a
static library is less than one US cent, and memory is little more.
There is another benefit/cost to shared libraries; rebuilding a shared
library changes that library for every application that uses it. If you
fix a c-client bug, then being a shared library means that you fix that
bug in every application without to rebuild that application. That's a
good thing.
However, you have to weigh that benefit against the cost of making certain
that the newer c-client shared library is binary compatible. It's easy
enough if you use the same source that was used to build the original
shared library, modulo the bugfix. If, on the other hand, the source
comes from a different release, it may not be binary compatible. You now
end up having to keep multiple versions of c-client shared library online
(since some application may use the older one), or take your chance of a
version skew, or simply rebuild everything over again.
With all this said, it will probably be a good idea to make c-client be a
shared library at some time in the future: after I die, or retire, or
embark upon a new project, or otherwise end my work on c-client. That
time is not yet (and as far as my demise, I hope not for quite some time
to come...). I just can't promise at this time that there won't be binary
level version skews, nor that I can be counted upon to note when such a
skew will occur (thus necessitating a change of shared library version).
-- Mark --
http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.
_______________________________________________
Imap-uw mailing list
[email protected]
https://mailman1.u.washington.edu/mailman/listinfo/imap-uw
