addpkg(x11/qt-creator): 18.0.0 #27309

robertkirkman · 2025-11-16T21:27:50Z

Reverts rmpkg(x11/qt-creator): Remove outdated package #27289
The software changed completely since the older version, so it is necessary to delete all the old patches and make new ones.
Necessary to enable RTTI in libllvm to fix this error that otherwise would occur when attempting to launch qtcreator:

qtc.extensionsystem.plugin: [ ClangFormat ] Plugin error:
/data/data/com.termux/files/usr/lib/qtcreator/plugins/libClangFormat.so:
Cannot load library /data/data/com.termux/files/usr/lib/qtcreator/plugins/libClangFormat.so:
dlopen failed: cannot locate symbol "_ZTIN4llvm3vfs10FileSystemE"
referenced by "/data/data/com.termux/files/usr/lib/qtcreator/plugins/libClangFormat.so"...

robertkirkman · 2025-11-16T21:33:42Z

It is working to create, compile and launch the default Hello World Qt project entirely using the GUI with just one tweak necessary. When you create the project, it is necessary to go to the settings and set the GUI equivalent of the CMake argument -DCMAKE_SYSTEM_NAME=Linux. Then it will work:

I could have maybe tried to make it automatically add that by default or something, but I'm not sure if I should or not, because, in Termux generally we don't make Qt automatically add that and instead we always add that explicitly whenever it's necessary, for every single affected Qt software,

termux-packages/x11-packages/qt6-qttranslations/build.sh

Line 14 in 8875df8

-DCMAKE_SYSTEM_NAME=Linux

so it feels like it might be kind of weird if it was always added automatically to every new Qt Creator project, because some projects might not need it, I feel like it should be consistent with the defaults of manually-built Qt projects in Termux.

robertkirkman · 2025-11-16T21:35:37Z

packages/libllvm/build.sh

@@ -62,6 +63,7 @@ TERMUX_PKG_EXTRA_CONFIGURE_ARGS="
 -DLLVM_EXPERIMENTAL_TARGETS_TO_BUILD=ARC;CSKY;M68k;VE
 -DPERL_EXECUTABLE=$(command -v perl)
 -DLLVM_ENABLE_FFI=ON
+-DLLVM_ENABLE_RTTI=ON


~~@fingolfin~~ @finagolfin is it ok with you to add this? When I didn't add this, an error happened to qt-creator that I recorded in the commit message here, but when I do this to libllvm it makes the error in qt-creator stop.

I think you pinged the wrong user

yes I'm really sorry... typo

I'm unaware of the tradeoffs of adding RTTI to LLVM, @Grimler91, @truboxl, @licy183, anyone else know about this?

What I know so far in favor other than that qt-creator needs it:

Arch Linux has it enabled https://gitlab.archlinux.org/archlinux/packaging/packages/llvm/-/blob/1130c251988f9e44a4d9af402cfcf42978b6d881/PKGBUILD#L93

What I know so far against this:

You previously rejected this libllvm: Enable RTTI #8031

Based on the discussion linked above, it sounds like if I try adding -fno-rtti to qt-creator, that might also fix the problem. I haven't tried that yet, so I will try that now.

If I do the calculation using only the packages that are pulled as dependencies when pkg install clang is used, clang, libcompiler-rt, libllvm, lld and llvm, the numbers are:

without -DLLVM_ENABLE_RTTI=ON: 480 MB
with -DLLVM_ENABLE_RTTI=ON: 490 MB

2% size increase

That sounds fine to me.

Size is not the main issue, the supposed performance hit was.

Based on the current error message, _ZTIN4llvm3vfs10FileSystemE means the typeinfo for llvm::vfs::FileSystem, which means QtCreator is using FileSystem's typeinfo in some code paths. It would be better to find out where it is being used and patch it, rather than enabling RTTI for libllvm.

I share the same concern as finagolfin. Enabling RTTI might cause significant performance degradation, so it's best to avoid enabling RTTI if possible.

I have now tested building mesa on Samsung Galaxy S8+ SM-G955F using both libllvm with -DLLVM_ENABLE_RTTI=ON and libllvm with -DLLVM_ENABLE_RTTI=OFF and compared the amount of time to build using the time command, but there did not appear to be a significant difference in the amount of time each build took.

Also, I know that, for example, Mesa is a software which itself involves LLVM_ENABLE_RTTI somehow and is not just a random software, because when libllvm has -DLLVM_ENABLE_RTTI=ON, the argument -Dcpp_rtti=false must be removed from the mesa build.sh to prevent a build error, and vice versa.

I wonder what the way is to reproduce a situation where the performance of libllvm is impacted.

When I tried this change in qt-creator,

--- a/src/plugins/clangformat/CMakeLists.txt +++ b/src/plugins/clangformat/CMakeLists.txt @@ -25,6 +25,8 @@ if(MSVC AND TARGET ClangFormat) target_compile_options(ClangFormat PUBLIC /wd4267 /wd4624) endif() +target_compile_options(ClangFormat PRIVATE -fno-rtti) + extend_qtc_plugin(ClangFormat CONDITION UNIX AND NOT APPLE PROPERTIES LINK_FLAGS "-Wl,--exclude-libs,ALL"

This error occurred.

/home/builder/.termux-build/qt-creator/src/src/plugins/clangformat/clangformatutils.cpp:202:31: error: use of dynamic_cast requires -frtti 202 | if (auto ccpPreferences = dynamic_cast<const CppEditor::CppCodeStylePreferences *>(preferences)) | ^ 1 error generated.

so unfortunatley, just -fno-rtti will not work, and to build qt-creator without requiring -DLLVM_ENABLE_RTTI=ON, it will be necessary to somehow remove the dependency on -DLLVM_ENABLE_RTTI=ON from it at a lower level, possibly somewhere in this file https://github.com/qt-creator/qt-creator/blob/master/src/plugins/clangformat/llvmfilesystem.h

I will continue trying to remove the dependency on -DLLVM_ENABLE_RTTI=ON from qt-creator.

x11-packages/qt-creator/build.sh

robertkirkman · 2025-11-17T13:24:55Z

It is not possible to build both packages in under 6 hours, so if the libllvm change is approved, I will separate it into 2 PRs.

licy183 · 2025-11-18T08:50:34Z

Theoretically, enabling RTTI would cause significant performance degradation, but it may not happen in tests. I guess it may happen when try compiling a very, very large C++ file.

licy183 · 2025-11-18T09:53:08Z

I checked most of the major distributions, such as Arch, Debian, Fedora, etc., and they all have libllvm's RTTI enabled. I don't object to enabling the RTTI option for libllvm, but if we finally choose to do it, all libllvm's reverse dependencies should get recompiled because that's an ABI change.

robertkirkman · 2025-11-18T11:03:02Z

Ok, I will try that,

Also, it can be mentioned that the other libc++-based Linux distro, Chimera, also has it enabled,

https://github.com/chimera-linux/cports/blob/b4a3f1d9d185f1d3a60b39d9e68e911be4e8c9f5/main/llvm/template.py#L25

And libc++-based UNIX-like operating system FreeBSD has it enabled,

https://github.com/freebsd/freebsd-ports/blob/c8378c42b782434f710044fe1f69795f926c7651/devel/llvm21/Makefile#L67

and libc++-based UNIX operating system MacOS has it enabled..

https://github.com/macports/macports-ports/blob/3bdc90a42ec6c27de62f52a73ef9893d0ea8d8ad/lang/llvm-21/Portfile#L83

It seems to me like it can be assumed that if there is a performance penalty, it is considered by other operating systems to be not bad enough to prevent the use of -DLLVM_ENABLE_RTTI=ON.

- Necessary to fix this error that otherwise would occur when attempting to launch the software `qt-creator`: ``` qtc.extensionsystem.plugin: [ ClangFormat ] Plugin error: /data/data/com.termux/files/usr/lib/qtcreator/plugins/libClangFormat.so: Cannot load library /data/data/com.termux/files/usr/lib/qtcreator/plugins/libClangFormat.so: dlopen failed: cannot locate symbol "_ZTIN4llvm3vfs10FileSystemE" referenced by "/data/data/com.termux/files/usr/lib/qtcreator/plugins/libClangFormat.so"... ``` - All other major UNIX-like operating systems enable this. See #27309 (comment)

- Change `TERMUX_PKG_GIT_BRANCH` to be equal to `TERMUX_PKG_VERSION` because it works

- Reverts termux#27289 - The software changed completely since the older version, so it is necessary to delete all the old patches and make new ones.

packages/lfortran/build.sh

- Necessary to fix this error that otherwise would occur when attempting to launch the software `qt-creator`: ``` qtc.extensionsystem.plugin: [ ClangFormat ] Plugin error: /data/data/com.termux/files/usr/lib/qtcreator/plugins/libClangFormat.so: Cannot load library /data/data/com.termux/files/usr/lib/qtcreator/plugins/libClangFormat.so: dlopen failed: cannot locate symbol "_ZTIN4llvm3vfs10FileSystemE" referenced by "/data/data/com.termux/files/usr/lib/qtcreator/plugins/libClangFormat.so"... ``` - All other major UNIX-like operating systems enable this. See termux/termux-packages#27309 (comment)

truboxl · 2025-11-20T03:35:35Z

So we are not going to investigate RTTI=OFF with qt-creator?

robertkirkman · 2025-11-20T03:53:28Z

So we are not going to investigate RTTI=OFF with qt-creator?

I will continue to, sure

finagolfin · 2025-11-20T08:45:21Z

So we are not going to investigate RTTI=OFF with qt-creator?

Given all the other distros he listed enabling it, I am fine with trying it and rolling back if we see any serious problems.

robertkirkman · 2025-11-23T09:55:41Z

I tried some things, but unfortunately I still don't know any way to make the error stop without either using -DLLVM_ENABLE_RTTI=ON, or disabling part of or the entire functionality of the ClangFormat plugin, which I could do here but it would remove functionality from the software.

One of the things I tried is removing all instances of QTC_ASSERT_RESULT() and QTC_ASSERT() from the clangformat folder, because I thought that might have something to do with it, but unfortunately that didn't help.

I will proceed to merge this soon unless someone can find a way to remove the dependency on -DLLVM_ENABLE_RTTI=ON without removing functionality from the software.

robertkirkman · 2025-11-24T20:38:38Z

I asked in the LLVM Discord server what they think about this problem and someone there said this:

This is that person's GitHub Account: https://github.com/zero9178

They have made PRs in LLVM that are merged, so I am inclined to believe their opinion about this.

I will merge this in 24 hours if there are no objections to this.

truboxl · 2025-11-25T01:32:38Z

I will look into the qt-creator with RTTI=OFF separately.

https://android.googlesource.com/platform/prebuilts/clang/host/linux-x86/+/refs/heads/main/clang-r530567/lib/cmake/llvm/LLVMConfig.cmake#201
The NDK we using also has LLVM_ENABLE_RTTI=OFF, so in case there is any discrepancy, we need to be aware of this.

So I am fine with this.

robertkirkman · 2025-11-25T01:50:10Z

The NDK we using also has LLVM_ENABLE_RTTI=OFF, so in case there is any discrepancy, we need to be aware of this.

It is true, and we should keep that in mind, though it seems to me that this is something that is ok if it's different between the cross-compiler and the non-cross-compiler, because, I noticed:

the setting primarily seems to change symbols inside the libLLVM.so file
the NDK cross-compiler does not provide any libLLVM.so, so any code which otherwise would form it is statically-linked inside the ~/.termux-build/_cache/android-r28c-api-24-v2/bin/clang, and if it did provide one, I think it wouldn't work on-device because it would be a libLLVM.so for GNU/Linux:

builder@5a3bbf31b055:~/termux-packages$ find ~/.termux-build/_cache/android-r28c-api-24-v2/ | grep libLLVM
builder@5a3bbf31b055:~/termux-packages$ ldd ~/.termux-build/_cache/android-r28c-api-24-v2/bin/clang
	linux-vdso.so.1 (0x00007f3491b8a000)
	libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f3491b73000)
	librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f3491b6e000)
	libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f3491b69000)
	libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f3489917000)
	libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f3491b4d000)
	libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f3491b1d000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f3489705000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f3491b8c000)
builder@5a3bbf31b055:~/termux-packages$

On the other hand, the non-cross-compiler does provide libLLVM.so, which is where the setting is causing changes, and the on-device clang is linked to it:

~/code $ ldd $PREFIX/bin/clang
	libc.so => /system/lib64/libc.so
	libclang-cpp.so => /data/data/com.termux/files/usr/lib/libclang-cpp.so
	libLLVM.so => /data/data/com.termux/files/usr/lib/libLLVM.so
	libc++_shared.so => /data/data/com.termux/files/usr/lib/libc++_shared.so
	ld-android.so => /system/lib64/ld-android.so
	libdl.so => /system/lib64/libdl.so
	libm.so => /system/lib64/libm.so
	libffi.so => /data/data/com.termux/files/usr/lib/libffi.so
	libz.so.1 => /data/data/com.termux/files/usr/lib/libz.so.1
	libzstd.so.1 => /data/data/com.termux/files/usr/lib/libzstd.so.1
	libxml2.so.16 => /data/data/com.termux/files/usr/lib/libxml2.so.16
	libicuuc.so.78 => /data/data/com.termux/files/usr/lib/libicuuc.so.78
	libiconv.so => /data/data/com.termux/files/usr/lib/libiconv.so
	libicudata.so.78 => /data/data/com.termux/files/usr/lib/libicudata.so.78

robertkirkman requested review from Grimler91, TomJo2000 and finagolfin as code owners November 16, 2025 21:27

robertkirkman requested a review from fornwall November 16, 2025 21:28

robertkirkman commented Nov 16, 2025

View reviewed changes

TomJo2000 reviewed Nov 16, 2025

View reviewed changes

x11-packages/qt-creator/build.sh Show resolved Hide resolved

robertkirkman marked this pull request as draft November 18, 2025 05:37

robertkirkman mentioned this pull request Nov 18, 2025

fix(main/libllvm): enable RTTI #27331

Merged

robertkirkman added 9 commits November 19, 2025 18:12

bump(main/ccls): 0.20250815.1

50318f9

- Change `TERMUX_PKG_GIT_BRANCH` to be equal to `TERMUX_PKG_VERSION` because it works

revbump(main/crystal): for -DLLVM_ENABLE_RTTI=ON

3db8429

revbump(main/iwyu): for -DLLVM_ENABLE_RTTI=ON

00b1ab6

revbump(main/libclc): for -DLLVM_ENABLE_RTTI=ON

c94b97a

revbump(main/mesa): for -DLLVM_ENABLE_RTTI=ON

71d0136

revbump(main/oidn): for -DLLVM_ENABLE_RTTI=ON

f77d3cb

revbump(main/rust): for -DLLVM_ENABLE_RTTI=ON

6e6b152

revbump(main/spirv-llvm-translator): for -DLLVM_ENABLE_RTTI=ON

808837d

addpkg(x11/qt-creator): 18.0.0

b4cdcfd

- Reverts termux#27289 - The software changed completely since the older version, so it is necessary to delete all the old patches and make new ones.

robertkirkman force-pushed the qt-creator-18.0.0 branch 2 times, most recently from b58f290 to b4cdcfd Compare November 20, 2025 00:23

robertkirkman commented Nov 20, 2025

View reviewed changes

packages/lfortran/build.sh Show resolved Hide resolved

revbump(main/lfortran): for -DLLVM_ENABLE_RTTI=ON

73eaea7

robertkirkman force-pushed the qt-creator-18.0.0 branch from 0dda4a8 to 73eaea7 Compare November 20, 2025 00:48

robertkirkman mentioned this pull request Nov 21, 2025

fix(main/mesa): Build with RTTI since LLVM now has it #27369

Closed

robertkirkman marked this pull request as ready for review November 23, 2025 09:55

robertkirkman merged commit 728885d into termux:master Nov 25, 2025
11 checks passed

TomJo2000 mentioned this pull request Nov 26, 2025

[Bug]: qt-creator dissappear #27424

Closed

Uh oh!

addpkg(x11/qt-creator): 18.0.0 #27309

addpkg(x11/qt-creator): 18.0.0 #27309

Uh oh!

Conversation

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

Uh oh!

Uh oh!

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

Uh oh!

Uh oh!

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

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!

Choose a reason for hiding this comment

Uh oh!

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

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

robertkirkman commented Nov 17, 2025

Uh oh!

licy183 commented Nov 18, 2025

Uh oh!

licy183 commented Nov 18, 2025

Uh oh!

robertkirkman commented Nov 18, 2025

Uh oh!

Uh oh!

truboxl commented Nov 20, 2025

Uh oh!

robertkirkman commented Nov 20, 2025

Uh oh!

finagolfin commented Nov 20, 2025

Uh oh!

robertkirkman commented Nov 23, 2025

Uh oh!

robertkirkman commented Nov 24, 2025

Uh oh!

truboxl commented Nov 25, 2025

Uh oh!

robertkirkman commented Nov 25, 2025

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants

robertkirkman commented Nov 16, 2025 •

edited

Loading

robertkirkman commented Nov 16, 2025 •

edited

Loading

robertkirkman Nov 16, 2025 •

edited

Loading

robertkirkman Nov 18, 2025 •

edited

Loading