LibreOffice 4.2.1.1 fails to build with ICU 53.1. [build CLR] CustomTarget/i18npool/collator/collator_ja_phonetic_alphanumeric_last.cxx S=/var/tmp/portage/app-office/libreoffice-4.2.1.1/work/libreoffice-4.2.1.1 && I=$S/instdir && W=$S/workdir && LD_LIBRARY_PATH=${LD_LIBRARY_PATH:+$LD_LIBRARY_PATH:}"$I/ure/lib:$I/program" $W/LinkTarget/Executable/gencoll_rule $S/i18npool/source/collator/data/ja_phonetic_alphanumeric_last.txt $W/CustomTarget/i18npool/collator/collator_ja_phonetic_alphanumeric_last.cxx ja_phonetic_alphanumeric_last [build CLR] CustomTarget/i18npool/collator/collator_ko_charset.cxx S=/var/tmp/portage/app-office/libreoffice-4.2.1.1/work/libreoffice-4.2.1.1 && I=$S/instdir && W=$S/workdir && LD_LIBRARY_PATH=${LD_LIBRARY_PATH:+$LD_LIBRARY_PATH:}"$I/ure/lib:$I/program" $W/LinkTarget/Executable/gencoll_rule $S/i18npool/source/collator/data/ko_charset.txt $W/CustomTarget/i18npool/collator/collator_ko_charset.cxx ko_charset Rule parsering error /var/tmp/portage/app-office/libreoffice-4.2.1.1/work/libreoffice-4.2.1.1/i18npool/CustomTarget_collator.mk:43: recipe for target '/var/tmp/portage/app-office/libreoffice-4.2.1.1/work/libreoffice-4.2.1.1/workdir/CustomTarget/i18npool/collator/collator_ko_charset.cxx' failed make[1]: *** [/var/tmp/portage/app-office/libreoffice-4.2.1.1/work/libreoffice-4.2.1.1/workdir/CustomTarget/i18npool/collator/collator_ko_charset.cxx] Error 1
Robert/Eike: seeing http://cgit.freedesktop.org/libreoffice/core/commit/?id=8ab4752820331ab80410877836093630198812d8, one for you?
I probably won't have an opportunity to look at it for the next few days, but will see if I can get around to it some time later this week.
Ping?
Can this one be fixed? LO cannot be build anymore on Mageia Linux due to having icu-5.3...
If you are not a package maintainer who is bound to use system ICU you could configure (./autogen.sh) with option --with-system-icu=no which uses the internal ICU version. I'll try to fix this.
We already tried that but LO fails to link in that case: See yesterday build: http://pkgsubmit.mageia.org/uploads/failure/cauldron/core/release/20140427163510.tv.valstar.24858/log/libreoffice-4.2.3.3-2.mga5/build.0.20140427163615.log libreoffice-4.2.3.3/workdir/CxxObject/i18npool/source/collator/gencoll_rule.o: In function `sal_main_with_args': libreoffice-4.2.3.3/i18npool/source/collator/gencoll_rule.cxx:115: undefined reference to `icu_52::UnicodeString::UnicodeString(unsigned short const*)' libreoffice-4.2.3.3/i18npool/source/collator/gencoll_rule.cxx:115: undefined reference to `icu_52::UMemory::operator new(unsigned int)' libreoffice-4.2.3.3/i18npool/source/collator/gencoll_rule.cxx:115: undefined reference to `icu_52::RuleBasedCollator::RuleBasedCollator(icu_52::UnicodeString const&, UErrorCode&)' libreoffice-4.2.3.3/i18npool/source/collator/gencoll_rule.cxx:115: undefined reference to `icu_52::UnicodeString::~UnicodeString()' libreoffice-4.2.3.3/i18npool/source/collator/gencoll_rule.cxx:120: undefined reference to `icu_52::RuleBasedCollator::cloneRuleData(int&, UErrorCode&)' libreoffice-4.2.3.3/i18npool/source/collator/gencoll_rule.cxx:128: undefined reference to `uprv_free_52' libreoffice-4.2.3.3/i18npool/source/collator/gencoll_rule.cxx:115: undefined reference to `icu_52::UMemory::operator delete(void*)' libreoffice-4.2.3.3/i18npool/source/collator/gencoll_rule.cxx:115: undefined reference to `icu_52::UnicodeString::~UnicodeString()' collect2: error: ld returned 1 exit status
Still valid with latest 4.2 RC
(In reply to comment #6) > We already tried that but LO fails to link in that case: That's odd. I built regularly with internal ICU and didn't encounter such a failure. On Fedora F18/F19 that was for 4.2 I suspect that this S=/home/iurt/rpmbuild/BUILD/libreoffice-4.2.3.3 && I=$S/instdir && W=$S/workdir && g++ -Wl,-z,origin '-Wl,-rpath,$ORIGIN/../Library' -Wl,-rpath-link,$I/ure/lib -Wl,-rpath-link,$I/program -Wl,-z,defs -Wl,-rpath-link,/lib:/usr/lib -Wl,-z,combreloc -Wl,--hash-style=gnu -Wl,--dynamic-list-cpp-new -Wl,--dynamic-list-cpp-typeinfo -Wl,-Bsymbolic-functions -L$W/LinkTarget/StaticLibrary -L$I/sdk/lib -L$I/ure/lib -L$I/program -L$W/LinkTarget/Library -Wl,--as-needed -Wl,--no-undefined -Wl,-z,relro -Wl,-O1 -Wl,--build-id -Wl,--enable-new-dtags -L/usr/lib $W/CxxObject/i18npool/source/collator/gencoll_rule.o -Wl,--start-group -L$W/UnpackedTarball/icu/source/lib -licudata -L$W/UnpackedTarball/icu/source/lib -licui18n -L$W/UnpackedTarball/icu/source/lib -licuuc -Wl,--end-group -Wl,--no-as-needed -luno_sal -o $W/LinkTarget/Executable/gencoll_rule somehow does not pull in the correct library paths on your system, though I don't spot an error there.
Great stuff.. ICU as of 53.1 checks Hangul syllables for contractions starting with Jamo L or V and refuses to process collation rules that contain them. Quoting from collationbuilder.cpp CollationBuilder::addRelation() "The runtime code decomposes Hangul syllables on the fly, with recursive processing but without making the Jamo pieces visible for matching. It does not work with certain types of contextual mappings." "While handling a Hangul syllable, contractions starting with Jamo L or V would not see the following Jamo of that syllable." (this is where we bail out already with the first syllable of ko_charset.txt) Another condition to fail is described as "A contraction ending with Jamo L or L+V would require generating Hangul syllables in addTailComposites() (588 for a Jamo L), or decomposing a following Hangul syllable on the fly, during contraction matching." Not being familiar at all with Korean, Hangul syllables or Jamo contractions I wonder if we can make further sense of ko_charset.txt at all, or if we have to drop it and hope that ICU in the mean time handles Korean collation sufficiently.
Eike Rathke committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=2d843bb104a3091a2ff2c7b4d5655f5fb1393a47 upgrade to ICU 53.1, fdo#77071 related The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
A subset patch that should enable build with ICU 53 is pending review for 4-2 at https://gerrit.libreoffice.org/9205
Eike Rathke committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=f02c7cdbef595660703cce9359fe9eb71ceefacf drop source/common/putilimp.h part of Android patch, fdo#77071 related The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
This fails with: Rule parsering error /home/iurt/rpmbuild/BUILD/libreoffice-4.2.4.1/i18npool/CustomTarget_collator.mk:46: recipe for target '/home/iurt/rpmbuild/BUILD/libreoffice-4.2.4.1/workdir/CustomTarget/i18npool/collator/collator_zh_TW_charset.cxx' failed (http://pkgsubmit.mageia.org/uploads/failure/cauldron/core/release/20140430053205.tv.valstar.17697/log/libreoffice-4.2.4.1-3.mga5/build.0.20140430053412.log) Using http://svnweb.mageia.org/packages/cauldron/libreoffice/current/SOURCES/icu-53.patch?view=markup
Eike Rathke committed a patch related to this issue. It has been pushed to "libreoffice-4-2": http://cgit.freedesktop.org/libreoffice/core/commit/?id=32a9c19bf79b99ae3b6cdae7ccc07499094a5603&h=libreoffice-4-2 adapt i18npool to ICU 53, fdo#77071 It will be available in LibreOffice 4.2.5. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
This needs further massaging as the RuleBasedCollator API lies about https://ssl.icu-project.org/apiref/icu4c/classicu_1_1RuleBasedCollator.html#a2f4c7eeaf020ad68e3bd9722dd272357 They changed behavior to bail out with an error if length is negative, which we so far used to create the runtime instance.
(In reply to comment #13) > This fails with: > Rule parsering error > /home/iurt/rpmbuild/BUILD/libreoffice-4.2.4.1/i18npool/CustomTarget_collator. > mk:46: recipe for target > '/home/iurt/rpmbuild/BUILD/libreoffice-4.2.4.1/workdir/CustomTarget/i18npool/ > collator/collator_zh_TW_charset.cxx' failed It didn't fail here, and not in all other builds the tinderboxes did in the mean time. > Using > http://svnweb.mageia.org/packages/cauldron/libreoffice/current/SOURCES/icu- > 53.patch?view=markup Make sure you don't destroy the encoding of zh_TW_charset.txt in the patch, already the first line +<å<å<å<å<å¡<å£<å§<ç©<ç³ looks invalid.
Eike Rathke committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=a3c627fe38236e82bc6008075d862b3cbfbd9ce3 resolve crashes with ICU 53.1 in locales with collator data, fdo#77071 The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
This last patch is pending review for 4-2 at https://gerrit.libreoffice.org/9215
Eike Rathke committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=dc7ba1af236ec28d399eff833d56608fde9fb70d make DISABLE_DYNLOADING on Android happy, fdo#77071 related The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
(In reply to comment #16) > Make sure you don't destroy the encoding of zh_TW_charset.txt in the patch, Looks like cgit corrupts patches...
Eike Rathke committed a patch related to this issue. It has been pushed to "libreoffice-4-2": http://cgit.freedesktop.org/libreoffice/core/commit/?id=1ce42d1001139a9168e9451dbd48a6daef95c691&h=libreoffice-4-2 resolve crashes with ICU 53.1 in locales with collator data, fdo#77071 It will be available in LibreOffice 4.2.5. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
I'm not sure it's related, but I cannot build libreoffice on Debian/Sid, with icu52 (52.1-3). icu53 is not yet in Debian repositories... The error is on linking: /home/eroux/softs/libreoffice-git/workdir/CxxObject/l10ntools/source/xmlparse.o: dans la fonction « (anonymous namespace)::lcl_QuotRange(icu_53::UnicodeString const&, int, int, bool) »: xmlparse.cxx:(.text+0x6a): référence indéfinie vers « vtable for icu_53::UnicodeString » (many follow). I've tried to add --with-system-icu=no to autogen.sh, without success... Thank you,
Elie, you somehow managed to mix things up.. looks like you compiled against the internal ICU 53 (hence the icu_53:* symbol) but tried to link against a different ICU. Check in config_host.mk what the actual values of the ICU_MAJOR and SYSTEM_ICU variables really are, and do a make module.clean for all modules that complain about icu_53:* not being found and build again.
Strangely, I have the same result with and without --with-system-icu=no : export ICU_MAJOR=53 export ICU_MINOR=1 ... export SYSTEM_ICU= I seem to have the good flags for internal icu (in both cases too...): export ICU_CFLAGS=$(gb_SPACE)-I/home/eroux/softs/libreoffice-git/workdir/UnpackedTarball/icu/source/i18n -I/home/eroux/softs/libreoffice-git/workdir/UnpackedTarball/icu/source/common export ICU_LIBS=$(gb_SPACE)-L/home/eroux/softs/libreoffice-git/workdir/UnpackedTarball/icu/source/lib The solution was to pass --with-system-icu=yes, but I have to admit I would have thought it would be the default, and why doesn't compilation work with internal ICU?