|
From: Andy H. <and...@gm...> - 2008-06-18 22:17:56
|
On Tue, Jun 10, 2008 at 11:54 AM, Jay Berkenbilt <ej...@ql...> wrote: > > I'm the maintainer of the ICU packages for the debian GNU/Linux > distribution. A few months ago, George Rhoten had made a suggestion > that I should be configuring ICU with the --disable-rename flag, and > in preparation for creating the ICU 4.0 packages, I looked into to his > suggestion and had some questions. He reported to me that he is no > longer working on ICU and suggested that I take this to the icu-design > mailing list. I have temporarily subscribed myself, and will > summarize here. It looks to me like your analysis of the questions surrounding ICU renaming is correct. > It also seems that, to guarantee binary > compatibility, there are a number of other things developers have to > do such as only using stable APIs and avoiding the C++ APIs. This is absolutely true. Running without renaming, and changing out the version of ICU behind installed applications would involve a greater risk of instability. The flip side is making available updated locale, language, Unicode & data that comes with a new version of the library. So it's not completely black and white, but I suspect continuing with renaming is safest. Let installed binary applications continue to run with the ICU version they were built with. -- Andy > > Here is my reply to George Rhoten's original message, with his message > quoted before it: > > ----------- > > In February, you sent me the following: > > "George Rhoten" <gr...@gm...> wrote: > >> Hi Jay, >> >> I was noticing how Debian is building the ICU libraries, and I have >> one suggestion. >> >> Instead of using the following in Debian's rules file: >> >> # specific to this package >> l_CONFIGURE += --disable-samples --enable-static --enable-weak-threads >> >> you might want to consider using the following instead: >> >> # specific to this package >> l_CONFIGURE += --disable-samples --enable-static --enable-weak-threads >> --disable-renaming >> >> The ICU User's Guide >> (http://www.icu-project.org/userguide/design.html#ICU_Binary_Compatibility) >> mentions the --disable-renaming configure option for ensuring binary >> compatibility between ICU releases. We usually recommend that OS >> vendors use this option. > > I was thinking about doing this for the 4.0 release, but I'm not sure > it's really the right thing for Debian. I hope you can clarify. The > documentation states that --disable-renaming prevents renaming of > symbols such that binary compatibility can be obtained across > releases. However, the shared libraries are built with an soname > based on the release. There is therefore no way an executable linked > with one version will run with another version unless someone makes > extra symbolic links or otherwise messes around with the installed > shared libraries. It also seems that, to guarantee binary > compatibility, there are a number of other things developers have to > do such as only using stable APIs and avoiding the C++ APIs. There is > no way I can guarantee this among debian users or even among the > packages that depend on debian. It seems to me that the safest thing > for debian would be to continue to enable renaming. Even if we > disable renaming, because the shared library sonames, we still won't > get binary compatibility across releases even for those that follow > the other guidelines. Have I made an error in my analysis? Please > let me know. Since the --disable-renaming and --enable-renaming > versions aren't binary compatible with each other (if I understand > correctly), I can't make this change until 4.0 anyway, and 4.0 will > unfortunately be too late to make it into the upcoming Lenny release. > (It's already too late for me to start a library transition with as > many reverse dependencies as ICU.) Either way, I'd like to make a > decision on this before my initial upload of 4.0. Thanks! > > ----------- > > In response to the above, he sent the following reply: > >> Since I don't work on ICU anymore, you may want to bring up the >> issue on the icu-design mailing list. Maybe --disable-renaming can >> be modified to remove the soname usage when the option is used. >> >> I know that Apple uses --disable-renaming so that they can >> distribute ICU, but they customize ICU in a way that creates a >> single libicucore library. AIX also distributes ICU, and I believe >> they use --disable-renaming; however, the soname concept isn't quite >> the same on that OS. >> >> It's probably better to discuss this before the d03 release. That >> way, any required changes may be able to make the 4.0 release. > > I'd welcome any suggestions on this point. Unless I hear otherwise, > my intention is to continue not using --disable-renaming and to > continue forcing an ICU transition for each new release of ICU that > changes the soname. This happens infrequently enough that it's not > that big a deal, and I've recently taken version number information > out of the development package version so that the transitions can be > largely automated. In order for me to be willing to use > --disable-renaming, I would need to believe that it is quite safe to > do so. Otherwise, keeping track of which applications need to be > rebuilt when ICU changes will be problematic. Thanks! > > -- > Jay Berkenbilt <ej...@ql...> > > ------------------------------------------------------------------------- > Check out the new SourceForge.net Marketplace. > It's the best place to buy or sell services for > just about anything Open Source. > http://sourceforge.net/services/buy/index.php > _______________________________________________ > icu-design mailing list > icu...@li... > To Un/Subscribe: https://lists.sourceforge.net/lists/listinfo/icu-design > |