On Mon, 08 Jan 2007 11:19:40 -0800 "Kevin B. McCarty" <kmccarty@Princeton.EDU> wrote: > Hello, > > I have a dumb library ABI question. Suppose I maintain a library > libfoo.so that has public functions A(), B() and C(). Now there is a > new release in which libfoo.so only provides A(), but it is now (newly) > dynamically linked against libbar.so, which has public functions B() and > C() with interfaces identical to the old B() and C() in the old version > of libfoo.so. How will applications linked against the original libfoo be able to locate the symbols B and C? As these are called directly from the application, the application would have to be linked against libbar. You are adding a new dependency to these applications, libbar. > Does libfoo.so need to have its soname bumped, since it no longer > provides B() and C()? I'd say yes. > Or can it keep the same soname since it still > indirectly provides B() and C() via its new dependency on libbar.so? It is not indirect because the application uses B and C, so the application needs to link directly against B and C or symbols will not be resolved. Indirect means that libfoo needs E() and F() from libbar but does not expose either E or F as public symbols. (I'm assuming here that there is are sufficient applications using publicly exposed symbols such that each symbol is used at least once.) Functions are being removed from libfoo - that needs a SONAME change. If the function names really are identical (which is not a GoodThing IMHO, each program should use it's own function namespace) then you cannot even "wrap" B and C. In my own library, when I want to remove a function, I deprecate it. If I replace B() with betterB () then B() is retained in the deprecated source file. It's usually best to retain B() exactly as-is, bugs and all. Wrapping betterB() around B() so that all calls to B() actually go to betterB() can lead to new and mysterious bugs, especially if the application may have "worked-around" the bugs in B(). Only wrap if you are certain that the old functionality is entirely preserved (e.g. if you use a flag in betterB() to indicate that the application is actually looking for the old B(). When I have finally deprecated all the symbols I want to remove, I bump the SONAME and remove them all in one go by simply not omitting the deprecated source file. This reduces the number of SONAME changes by collating all changes into one. A better solution for libfoo, IMHO, is for libbar to use barB() and barC () then libfoo can retain B() and C() until such time as all applications have migrated to barB and barC. -- Neil Williams ============= http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/
Attachment:
pgpKefjz0YcI6.pgp
Description: PGP signature