Apache OpenOffice (AOO) Bugzilla – Full Text Issue Listing |
Summary: | In 680m235, i18npool fails to build with system icu | ||||||
---|---|---|---|---|---|---|---|
Product: | Internationalization | Reporter: | ht990332 <ht990332> | ||||
Component: | i18npool | Assignee: | ooo | ||||
Status: | CLOSED FIXED | QA Contact: | issues@l10n <issues> | ||||
Severity: | Trivial | ||||||
Priority: | P1 (highest) | CC: | andreas.radke, caolanm, issues, karl.hong, oliver.bolte, pavel, rene | ||||
Version: | 680m235 | Keywords: | regression | ||||
Target Milestone: | --- | ||||||
Hardware: | All | ||||||
OS: | All | ||||||
Issue Type: | DEFECT | Latest Confirmation in: | --- | ||||
Developer Difficulty: | --- | ||||||
Attachments: |
|
Description
ht990332
2007-10-31 03:49:47 UTC
There isn't much we can do about that right now. OOo's ICU was patched for a public method that was needed to fix issue 81519. You'll need to either use OOo's ICU or patch system's ICU in source/common/unicode/rbbi.h to make setBreakType() public: public: virtual void setBreakType(int32_t type); protected: However, patching the system's ICU and exposing setBreakType() to the outer world may not be wanted because the method is intended to be an internal method. @khong: Karl, from the short discussion on the ICU mailing list I conclude that handling this differently would imply redefining the Thai dictionary and to use some ICU service hooks. That sounds like much work, do you have any overview what it would take? Thanks Eike er: in that case the cws sttill was broken because it didbn't add a check for that function to the ICU configure check... And you could have coordinated this. This now also breaks system-icu with 2.3.1... :/ proposed patch which gives the following with plain libicu: checking which icu to use... external checking for unicode/rbbi.h... checked. checking for genbrk... /usr/bin/genbrk checking for genccode... /usr/sbin/genccode checking for gencmn... /usr/sbin/gencmn checking ICU version... OK checking for setBreakType in -licu... no configure: error: setBreakType needed public: in libicu is --- configure.in 25 Oct 2007 16:00:29 -0000 1.223 +++ configure.in 31 Oct 2007 13:19:04 -0000 @@ -3780,6 +3780,8 @@ else return 1; } ], [AC_MSG_RESULT(OK)], [AC_MSG_RESULT([not suitable, only 3.6 supported currently])]) + AC_CHECK_LIB(icu, setBreakType, [], + [AC_MSG_ERROR(setBreakType needed public: in libicu)], []) else AC_MSG_RESULT([internal]) SYSTEM_ICU=NO Of course, it would have been better if you didn't deliberately break compatibility with system-icu in a *bugfix-only* release.... Setting regression keyword... 3.6 probably will have the same problem, adapting summary Sorry for not thinking of --with-system-icu before, alarm should had rang when Karl told me about the fix. I'm not convinced of AC_CHECK_LIB(icu, setBreakType, ...) I didn't try, but I doubt it would not fail if setBreakType() was public, since that is a member method of a class inside a namespace: icu_3_8::RuleBasedBreakIterator::setBreakType(int32_t) How could that be treated with configure? Btw, the library is libicuuc.so er: hmm, good points, I should not have done this after coming back after having travelled the half day. back tp the drawing board. Will build a "fixed" icu and check... Eike, I go back to check the question I posted, I don't see anyon suggested to use service hooks. Which thread you see the discussion? Created attachment 49302 [details]
configure check
er: ok, if there's no other way to fix this (a solution which works with the normal icu of course is the best wa<..), the workaround of checking for a patched configure is the only solution. The just attached patch does this (and works, tested it with patched and unpatched, and also with 3.6 and 3.8) Looks viable, I'll promote this on dev@releases for 2.3.1 @khong: Karl, the service hooks were mentioned by George Rhoten on 2007-09-20 in an answer to your question on the icu-support list, see Message-Id: <OF29B7CED7.A82FB332-ON8625735C.00531CC9-8825735C.00543647@us.ibm.com> Unfortunately his mail was base64 encoded, so pointing to http://sourceforge.net/mailarchive/forum.php?thread_name=OF29B7CED7.A82FB332-ON8625735C.00531CC9-8825735C.00543647%40us.ibm.com&forum_name=icu-support is rather useless or at least cumbersome.. If the mail didn't reach you I can forward it (already decoded ;-) Let's take that off this issue though. . Retargeting to 2.3.1 Patch (attachment with id=49302) submitted as masterfix for OOG680 m8. Now also comitted to SRC680 code line. configure re-generated for both cases. -> fixed Present in master, closing. |