On Mon, May 25, 2009 at 2:28 PM, Marvin Humphrey I've long thought that we would eventually need something like tha<[email protected]> wrote: > However, this problem aflicts not just Perl and CPAN, but any dynamically > loaded shared library. Statically linked compiled apps are spared, because > you get to fix problems at compile time while the live app carries on, then > swap in the new app when you've finished troubleshooting. But any time live > apps have symbols being resolved at run time, upgrading the shared library > becomes problematic.
Really? I don't remember hitting any such problems with switching binaries since SunOs. I think you are overthinking this, Marvin. At least on Linux, shared library versioning works pretty well. And while I'm sure there are corner cases in the XS layer, in practice I've never run into much of a problem with it as a frequent user. > but if a process loads two shared libraries which both contain > the symbol 'lucy_Indexer_new', the conflict resolution process is platform > dependent. We can't count on sane behavior. Then don't do that. (Doctor, it hurts if I poke my finger into my eye!) Alternatively, don't try to support systems that do not provide sane behaviour. But why would a process be loading two shared libraries with incompatible ABI's, and what would be the sane behaviour you desire? > In it, "settings" objects, and "actsAsVersion" variables were discussed as > ways to offer Java Lucene users the fruits of innovation without major version > breaks, when the innovations would otherwise cause backwards compat problems. I didn't read this closely, but this seems to overlap with the built in symbol versioning available for C libraries: http://people.redhat.com/drepper/dsohowto.pdf "Maintaining APIs and ABIs" starts on page 34 and has relevant discussion. Are these features lacking for some other system you want to support? > Different versions of Lucy could > actually be loaded at the same time under this model, so the system-specific > equivalents of liblucy.dylib and liblucy.2.dylib would have no problem > co-existing. Sure, they could coexist, but it's unlikely they could share any data. I guess this would help if Lucy is being used as a purely internal component of another library, but this seems like a rare case. Note also that on LInux these two can coexist even if the symbols names are identical, as the dynamic loader supports symbol versioning. > Furthermore, "Lucy" is short, ends with a vowel > sound, and has an agreeable accent pattern -- so "Lucy2", "Lucy3", etc. roll > off of the tongue pretty easily. Yes, this is a fine naming convention if it turns out to be necessary to go this route. But don't worry about it yet! It's open source software --- if people run into problems they can just recompile. Release, release, release! Every library ever written faces these same issues, and most of them are doing fine. Get more people using this and worry about how to keep them happy later. Nathan Kurz [email protected] ps. Alternatively, you could provide a clearer test case that illustrates the problems you fear. Binary-only distributions of mutally-dependent extensions? I'm not seeing any common ones that can't be solved by standard dynamic library versioning.
