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.

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

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.

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.

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.

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.

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

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

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.

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.

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,

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

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.

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();
   |                   ++      +

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.

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.

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.

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

Thanks, will be testing that again.