bump(main/libicu): 78.1 #27221

TomJo2000 · 2025-11-12T20:23:27Z

closes Auto update failing for libicu #27219

Currently fails with symbol errors.
Need to investigate.

Rebuild list:

libicu

Can be done in this PR:

Probably need their own PRs:

dotnet8.0 (revbump(main/dotnet-8.0): libicu 78.1 rebuild #27235)
dotnet9.0 (revbump(main/dotnet-9.0): libicu 78.1 rebuild #27236)
firefox (revbump(x11/firefox): libicu 78.1 rebuild #27312)
nodejs (revbump(main/nodejs): libicu 78.1 rebuild #27237)
nodejs-lts (revbump(main/nodejs-lts): libicu 78.1 rebuild #27238)
qt5-qtbase, qt6-qt5compat, qt6-qtbase (revbump(x11/qt{5,6}-base,x11/qt6-qt5compat): libicu 78.1 rebuild #27239)
thunderbird (revbump(x11/thunderbird): libicu 78.1 rebuild #27313)
webkit2gtk-4.1 (revbump(x11/webkit2gtk-4.1): libicu 78.1 rebuild #27240)
webkitgtk-6.0 (BORKED pending scripts(toolchain): Update NDK to r29 #27089 ~~revbump(x11/webkitgtk-6.0): libicu 78.1 rebuild #27241~~)

TomJo2000 · 2025-11-12T20:56:01Z

Arch dropped ICU-22132.patch for 78.1
https://gitlab.archlinux.org/archlinux/packaging/packages/icu/-/commit/8637e8414c14f1a8c346a9a8337a318193794db6

This patch was previously necessary for Thunderbird 115's calender tab to function correctly.
This appears to no longer be a problem.

Still no lead on the symbol issues, can't get it to add -v to the LDFLAGS either.

Linker errors:

make[1]: Making `all' in `makeconv'
make[2]: Entering directory '/home/builder/.termux-build/libicu/build/tools/makeconv'
   (deps)        /home/builder/.termux-build/libicu/src/source/tools/makeconv/ucnvstat.c
   (deps)        /home/builder/.termux-build/libicu/src/source/tools/makeconv/makeconv.cpp
   (deps)        /home/builder/.termux-build/libicu/src/source/tools/makeconv/genmbcs.cpp
   (deps)        /home/builder/.termux-build/libicu/src/source/tools/makeconv/gencnvex.c
   aarch64-linux-android-clang   ...  /home/builder/.termux-build/libicu/src/source/tools/makeconv/gencnvex.c
cd ../.. \
 && CONFIG_FILES=tools/makeconv/makeconv.1 CONFIG_HEADERS= /bin/bash ./config.status
   aarch64-linux-android-clang++         ...  /home/builder/.termux-build/libicu/src/source/tools/makeconv/genmbcs.cpp
   aarch64-linux-android-clang++         ...  /home/builder/.termux-build/libicu/src/source/tools/makeconv/makeconv.cpp
   aarch64-linux-android-clang   ...  /home/builder/.termux-build/libicu/src/source/tools/makeconv/ucnvstat.c
config.status: creating tools/makeconv/makeconv.1
aarch64-linux-android-clang++ -fstack-protector-strong -Oz -W -Wall -pedantic -Wpointer-arith -Wwrite-strings -Wno-long-long -std=c++17   -L/data/data/com.termux/files/usr/lib -Wl,-rpath=/data/data/com.termux/files/usr/lib -Wl,--enable-new-dtags -Wl,--as-needed -Wl,-z,relro,-z,now   -o ../../bin/makeconv gencnvex.o genmbcs.o makeconv.o ucnvstat.o -L../../lib -licutu -L../../lib -licui18n -L../../lib -licuuc -L../../stubdata -licudata -lpthread -lm
ld.lld: error: undefined symbol: uprv_malloc_78
>>> referenced by gencnvex.c
>>>               gencnvex.o:(CnvExtOpen)
>>> referenced by genmbcs.cpp
>>>               genmbcs.o:(MBCSOpen)
>>> referenced by genmbcs.cpp
>>>               genmbcs.o:(MBCSAddTable(NewConverter*, UCMTable*, UConverterStaticData*))
>>> referenced 1 more times

ld.lld: error: undefined symbol: uprv_free_78
>>> referenced by gencnvex.c
>>>               gencnvex.o:(CnvExtClose)
>>> referenced by genmbcs.cpp
>>>               genmbcs.o:(MBCSClose(NewConverter*))
>>> referenced by genmbcs.cpp
>>>               genmbcs.o:(MBCSClose(NewConverter*))
>>> referenced 2 more times

ld.lld: error: undefined symbol: u_strFromUTF32_78
>>> referenced by gencnvex.c
>>>               gencnvex.o:(generateToUTable)
>>> referenced by gencnvex.c
>>>               gencnvex.o:(generateToUTable)

ld.lld: error: undefined symbol: u_getVersion_78
>>> referenced by makeconv.cpp
>>>               makeconv.o:(main)

ld.lld: error: undefined symbol: u_getDataDirectory_78
>>> referenced by makeconv.cpp
>>>               makeconv.o:(main)

ld.lld: error: undefined symbol: icu_78::StringPiece::StringPiece(char const*)
>>> referenced by makeconv.cpp
>>>               makeconv.o:(main)
>>> referenced by makeconv.cpp
>>>               makeconv.o:(main)
>>> referenced by makeconv.cpp
>>>               makeconv.o:(main)
>>> referenced 3 more times

ld.lld: error: undefined symbol: icu_78::CharString::ensureEndsWithFileSeparator(UErrorCode&)
>>> referenced by makeconv.cpp
>>>               makeconv.o:(main)

ld.lld: error: undefined symbol: icu_78::CharString::truncate(int)
>>> referenced by makeconv.cpp
>>>               makeconv.o:(main)
>>> referenced by makeconv.cpp
>>>               makeconv.o:(main)

ld.lld: error: undefined symbol: icu_78::CharString::lastIndexOf(char) const
>>> referenced by makeconv.cpp
>>>               makeconv.o:(main)

ld.lld: error: undefined symbol: uprv_stricmp_78
>>> referenced by makeconv.cpp
>>>               makeconv.o:(main)

ld.lld: error: undefined symbol: uprv_isInvariantString_78
>>> referenced by makeconv.cpp
>>>               makeconv.o:(main)

ld.lld: error: undefined symbol: u_errorName_78
>>> referenced by makeconv.cpp
>>>               makeconv.o:(main)
>>> referenced by makeconv.cpp
>>>               makeconv.o:(main)
>>> referenced by makeconv.cpp
>>>               makeconv.o:(main)

ld.lld: error: undefined symbol: icu_78::CharString::appendPathPart(icu_78::StringPiece, UErrorCode&)
>>> referenced by makeconv.cpp
>>>               makeconv.o:(OUTLINED_FUNCTION_14)

ld.lld: error: undefined symbol: icu_78::CharString::append(char const*, int, UErrorCode&)
>>> referenced by makeconv.cpp
>>>               makeconv.o:(icu_78::CharString::append(icu_78::StringPiece, UErrorCode&))
clang++: error: linker command failed with exit code 1 (use -v to see invocation)
make[2]: *** [Makefile:81: ../../bin/makeconv] Error 1
make[2]: Leaving directory '/home/builder/.termux-build/libicu/build/tools/makeconv'
make[1]: *** [Makefile:47: all-recursive] Error 2
make[1]: Leaving directory '/home/builder/.termux-build/libicu/build/tools'
make: *** [Makefile:153: all-recursive] Error 2

robertkirkman · 2025-11-13T03:50:49Z

packages/libicu/build.sh

 }

 termux_step_post_massage() {
 	local _GUARD_FILE="lib/libicuuc.so.77"


This should be incremented, and at the same time, all reverse dependencies rebuilt.

robertkirkman · 2025-11-13T03:58:46Z

packages/libicu/icu-22132.patch

-Fixes the VTIMEZONE generator of libicu producing an invalid VTIMEZONE,
-which if unpatched, would cause the error
-JavaScript error: resource:///modules/calendar/Ical.sys.mjs, line 1942: ParserError: invalid line (no token ";" or ":") "America/Chicago[2025a]"
-in Thunderbird 115 and newer, which would cause multiple UI elements to be missing or broken.


You can remove this if you want, but I am personally very certain that removing it would break Termux's thunderbird and make Termux's thunderbird borderline unusably bugged.

The reason why Arch Linux might have removed it is because:

They removed --with-system-icu from their thunderbird package https://gitlab.archlinux.org/archlinux/packaging/packages/thunderbird/-/commit/ec006d89f73d603595724c974cfce4518d1df9fa

(which might be a bit awkward for us to follow as an example because our libicu package has other patches including an Android-specific patch)

Thunderbird 144 (and also Firefox 145) don't currently compile with libicu 78 because of an unrelated compilation error, so they might have taken that to mean there seemed to be no need for them to keep the patch applied at the moment

personally I think Arch Linux's decision to immediately remove the patch when they could no longer compile Thunderbird with unvendored libicu is questionable, but if you want to follow what they do closely, you can go for it.

I'd prefer to try to compile Termux thunderbird with libicu 78 by patching Thunderbird + Firefox, if possible. I kind of think I understand the error a little bit so I might be able to.

I managed to make a patch which makes Firefox and Thunderbird compile with libicu 78 without the error.

My patch is original code, but is based on my research of looking at this previous change in Firefox/Thunderbird

https://hg-edge.mozilla.org/try/rev/d5f3b0c4f08a426ce00a153c04e177eecb6820e2

and combining it with this commit in libicu 78

unicode-org/icu@ccacd46

--- a/intl/lwbrk/LineBreaker.cpp +++ b/intl/lwbrk/LineBreaker.cpp @@ -454,6 +454,7 @@ static int8_t GetClass(uint32_t u, LineBreakRule aLevel, /* AKSARA_START = 45, [AS] */ CLASS_CHARACTER, /* VIRAMA_FINAL = 46, [VF] */ CLASS_CHARACTER, /* VIRAMA = 47, [VI] */ CLASS_CHARACTER, + /* U_LB_UNAMBIGUOUS_HYPHEN = 48, [HH] */ CLASS_CHARACTER, }; static_assert(U_LB_COUNT == std::size(sUnicodeLineBreakToClass),

Probably best to just keep the existing patch then if it still solves the issue.

I managed to make a patch which makes Firefox and Thunderbird compile with libicu 78 without the error.

My patch is original code, but is based on my research of looking at this previous change in Firefox/Thunderbird

https://hg-edge.mozilla.org/try/rev/d5f3b0c4f08a426ce00a153c04e177eecb6820e2

and combining it with this commit in libicu 78

unicode-org/icu@ccacd46

--- a/intl/lwbrk/LineBreaker.cpp +++ b/intl/lwbrk/LineBreaker.cpp @@ -454,6 +454,7 @@ static int8_t GetClass(uint32_t u, LineBreakRule aLevel, /* AKSARA_START = 45, [AS] */ CLASS_CHARACTER, /* VIRAMA_FINAL = 46, [VF] */ CLASS_CHARACTER, /* VIRAMA = 47, [VI] */ CLASS_CHARACTER, + /* U_LB_UNAMBIGUOUS_HYPHEN = 48, [HH] */ CLASS_CHARACTER, }; static_assert(U_LB_COUNT == std::size(sUnicodeLineBreakToClass),

Actually, if that's the entire patch, I can definitely add that to Firefox/Thunderbird and we'll just drop the libicu patch.

Actually, if that's the entire patch, I can definitely add that to Firefox/Thunderbird and we'll just drop the libicu patch.

like I explained, removing the libicu patch will probably cause thunderbird to become extremely messed up and glitchy, but if you really want to remove it you can and then I might request to add it back afterward if I can still reproduce the problem.

Probably best to just keep the existing patch then if it still solves the issue.

there are two separate issues involving thunderbird, one of them is fixed by the LineBreaker.cpp patch and the other one is fixed by the libicu patch

Eh let's keep it for now and we can test if your patch above is a suitable replacement later.

robertkirkman · 2025-11-13T05:27:02Z

Currently fails with symbol errors.

I have determined that the symbol errors are prefix pollution libicu 77.1 -> libicu 78.1 . I don't know a good way to work around them other than that to avoid those errors, you must build using a clean Docker container by using docker container kill termux-package-builder and then docker container rm termux-package-builder.

TomJo2000 · 2025-11-13T15:41:14Z

Currently fails with symbol errors.

I have determined that the symbol errors are prefix pollution libicu 77.1 -> libicu 78.1 . I don't know a good way to work around them other than that to avoid those errors, you must build using a clean Docker container by using docker container kill termux-package-builder and then docker container rm termux-package-builder.

Should have thought of that, must have been from the ffmpeg rebuild tests.

robertkirkman · 2025-11-13T16:39:06Z

There is a problem with libgnustep-base with NDK r28c, but it has to do with Objective-C and unfortunately I don't understand it and have not been able to fix that.

TomJo2000 · 2025-11-13T17:06:27Z

There is a problem with libgnustep-base with NDK r28c, but it has to do with Objective-C and unfortunately I don't understand it and have not been able to fix that.

Yeah I got nothing...
I can try making the linker more verbose, but I don't think I'm gonna be able to solve this.
I'll split it out into a separate branch, and if we can't get libgnustep-base building I think we should consider (temporarily) disabling it until we can get it to build against NDK 28c/29.

TomJo2000 · 2025-11-13T17:26:28Z

Looks like webkitgtk-6.0 ran into a Skia issue.
https://github.com/termux/termux-packages/actions/runs/19338839751/job/55321406364

TomJo2000 · 2025-11-13T17:29:26Z

The CI is getting hit pretty hard by the rebuilds.
I'll cancel the current batch and we'll do the FFMPEG one first.

robertkirkman · 2025-11-13T20:13:20Z

Looks like webkitgtk-6.0 ran into a Skia issue. https://github.com/termux/termux-packages/actions/runs/19338839751/job/55321406364

That is also related to NDK r28c. I tried to fix that for a long time (several months), but I haven't been able to. The error is extremely complicated.

I believe the error is likely to be reproducible on FreeBSD once FreeBSD attempts to bump their webkit2-gtk package to a version closer to the version that Termux packaged. I also believe that the error might also be possible to bisect not only to NDK r28c, but also to a commit somewhere in between webkitgtk 2.46.5 and webkitgtk 2.48.0. I haven't confirmed that.

TomJo2000 · 2025-11-14T00:30:01Z

CI was running out of space.
It looks like it was spidermonkey's fault.
It's full build directory grows to about 6.7GiB.
So I added it to big-pkgs.list.

robertkirkman · 2025-11-14T02:01:19Z

tectonic

This error in the current Rust in some packages error: implicit autoref creates a reference to the dereference of a raw pointer can be coerced to warning in the general case by inserting #![warn(dangerous_implicit_autorefs)] at the top of the .rs file in between the end of the first comment and the beginning of the first code,

termux-packages/x11-packages/thunderbird/0035-fix-for-rust-1.89.patch

Line 7 in e74419f

+#![warn(dangerous_implicit_autorefs)]

but I'm not sure if there is any case where doing that could have a side effect or not. I don't really know what it means

TomJo2000 · 2025-11-14T02:23:32Z

Got everything that will build building now.

Let's look at the damage.

libgnustep-base takes unar with it as a revdep.
webkitgtk-6.0 takes epiphany and zenity with it.
- zenity takes down marco, which would take down MATE, so that's an immediate blocker for the whole rebuild.

This PR cannot go ahead until we have webkitgtk-6.0 building again.

TomJo2000 · 2025-11-14T02:26:55Z

tectonic

This error in the current Rust in some packages error: implicit autoref creates a reference to the dereference of a raw pointer can be coerced to warning in the general case by inserting #![warn(dangerous_implicit_autorefs)] at the top of the .rs file in between the end of the first comment and the beginning of the first code,

termux-packages/x11-packages/thunderbird/0035-fix-for-rust-1.89.patch

Line 7 in e74419f

+#![warn(dangerous_implicit_autorefs)]

but I'm not sure if there is any case where doing that could have a side effect or not. I don't really know what it means

I just applied cargo's suggestion of making it explicitly a raw pointer.

help: try using a raw pointer method instead; or if this reference is intentional, make it explicit
   |
55 |     let old_len = (&(*old)).len();
   |                   ++      +

TomJo2000 · 2025-11-14T02:35:05Z

Looks like webkitgtk-6.0 ran into a Skia issue. https://github.com/termux/termux-packages/actions/runs/19338839751/job/55321406364

That is also related to NDK r28c. I tried to fix that for a long time (several months), but I haven't been able to. The error is extremely complicated.

I believe the error is likely to be reproducible on FreeBSD once FreeBSD attempts to bump their webkit2-gtk package to a version closer to the version that Termux packaged. I also believe that the error might also be possible to bisect not only to NDK r28c, but also to a commit somewhere in between webkitgtk 2.46.5 and webkitgtk 2.48.0. I haven't confirmed that.

OpenBSD has it at 2.50.1, that might be helpful?
https://github.com/openbsd/ports/blob/master/www/webkitgtk4/Makefile

Though I assume you've already looked at that.

robertkirkman · 2025-11-14T02:46:23Z

OpenBSD has it at 2.50.1, that might be helpful?
https://github.com/openbsd/ports/blob/master/www/webkitgtk4/Makefile
Though I assume you've already looked at that.

I did not know that, thanks. That makes it seem like the issue is completely specific to Android, but there could be an unknown difference between the build settings of each package.

robertkirkman · 2025-11-15T18:27:58Z

There is a problem with libgnustep-base with NDK r28c, but it has to do with Objective-C and unfortunately I don't understand it and have not been able to fix that.

I might have started to figure out what is wrong with libgnustep-base. After a long time of thinking, I think I can see now what is wrong with it. Wait some time and I might be able to fix it.

licy183 · 2025-11-17T10:40:43Z

The build error in webkitgtk-6.0 should be fixed by #27317.

TomJo2000 requested a review from Grimler91 as a code owner November 12, 2025 20:23

TomJo2000 requested review from MrAdityaAlok, licy183 and thunder-coding November 12, 2025 20:26

TomJo2000 force-pushed the libicu-78 branch from fbb9d98 to e74aaea Compare November 12, 2025 20:56

robertkirkman reviewed Nov 13, 2025

View reviewed changes

TomJo2000 force-pushed the libicu-78 branch from e74aaea to d723721 Compare November 13, 2025 16:23

This was referenced Nov 13, 2025

revbump(main/dotnet-8.0): libicu 78.1 rebuild #27235

Open

revbump(main/dotnet-9.0): libicu 78.1 rebuild #27236

Open

TomJo2000 force-pushed the libicu-78 branch from d723721 to 5a1f510 Compare November 13, 2025 17:17

TomJo2000 force-pushed the libicu-78 branch from 5a1f510 to baae9af Compare November 13, 2025 23:04

TomJo2000 added 5 commits November 14, 2025 01:28

bump(main/libicu): 78.1

22a1e1f

revbump(main/harfbuzz): libicu 78.1 rebuild

6a4367a

revbump(main/libical): libicu 78.1 rebuild

1015f00

revbump(main/libkiwix): libicu 78.1 rebuild

1569f65

revbump(main/libraptor2): libicu 78.1 rebuild

c9077b7

TomJo2000 added 3 commits November 14, 2025 01:28

revbump(main/postgresql): libicu 78.1 rebuild

921b8e4

revbump(main/samba): libicu 78.1 rebuild

07c3728

revbump(main/spidermonkey): libicu 78.1 rebuild

73f74df

TomJo2000 force-pushed the libicu-78 branch from baae9af to 5451397 Compare November 14, 2025 00:28

TomJo2000 added 13 commits November 14, 2025 03:16

revbump(main/tectonic): libicu 78.1 rebuild

436f1b4

revbump(main/tesseract): libicu 78.1 rebuild

d3cd3cb

revbump(main/texlive-bin): libicu 78.1 rebuild

12250b4

revbump(main/tinysparql): libicu 78.1 rebuild

e92e52f

revbump(main/unar): libicu 78.1 rebuild

235766b

revbump(main/znc): libicu 78.1 rebuild

7ade0a8

revbump(x11/freerdp): libicu 78.1 rebuild

70b733b

revbump(x11/gspell): libicu 78.1 rebuild

31f2e3c

revbump(x11/gw): libicu 78.1 rebuild

12a25ee

revbump(x11/libgedit-tepl): libicu 78.1 rebuild

b7eed83

revbump(x11/libspelling): libicu 78.1 rebuild

70741f1

revbump(x11/libvte): libicu 78.1 rebuild

e2a57b2

revbump(x11/openttd): libicu 78.1 rebuild

a9cc1bf

TomJo2000 force-pushed the libicu-78 branch from 5451397 to a9cc1bf Compare November 14, 2025 02:16

TomJo2000 marked this pull request as draft November 14, 2025 02:23

This was referenced Nov 15, 2025

fix(main/libgnustep-base): remove build tool manipulation #27286

Merged

revbump(x11/firefox): libicu 78.1 rebuild #27312

Open

revbump(x11/thunderbird): libicu 78.1 rebuild #27313

Open

Uh oh!

bump(main/libicu): 78.1 #27221

Are you sure you want to change the base?

bump(main/libicu): 78.1 #27221

Conversation

TomJo2000 commented Nov 12, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Can be done in this PR:

Probably need their own PRs:

Uh oh!

TomJo2000 commented Nov 12, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

robertkirkman commented Nov 13, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

TomJo2000 commented Nov 13, 2025

Uh oh!

robertkirkman commented Nov 13, 2025

Uh oh!

TomJo2000 commented Nov 13, 2025

Uh oh!

TomJo2000 commented Nov 13, 2025

Uh oh!

TomJo2000 commented Nov 13, 2025

Uh oh!

robertkirkman commented Nov 13, 2025

Uh oh!

TomJo2000 commented Nov 14, 2025

Uh oh!

robertkirkman commented Nov 14, 2025

Uh oh!

TomJo2000 commented Nov 14, 2025

Uh oh!

TomJo2000 commented Nov 14, 2025

Uh oh!

TomJo2000 commented Nov 14, 2025

Uh oh!

robertkirkman commented Nov 14, 2025

Uh oh!

robertkirkman commented Nov 15, 2025

Uh oh!

licy183 commented Nov 17, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

TomJo2000 commented Nov 12, 2025 •

edited

Loading

robertkirkman commented Nov 13, 2025 •

edited

Loading