[PATCH 0/1] MR10936: sqlite3: Use __sync_synchronize() with clang.
libs/sqlite3: Use __sync_synchronize() with clang. When building sqlite3 for PE with clang, the MSVC_VERSION check may select the _ReadWriteBarrier() path. However, _ReadWriteBarrier() is not declared in this translation unit, causing the build to fail: ``` aarch64-w64-mingw32-clang -D__STDC__ -c -o libs/sqlite3/aarch64-windows/sqlite3.o ... -D_UCRT -DSQLITE_ENABLE_RTREE=1 \ -DSQLITE_ENABLE_FTS4=1 -DSQLITE_ENABLE_COLUMN_METADATA=1 -DSQLITE_DEBUG=1 -DSQLITE_SYSTEM_MALLOC=1 \ -DSQLITE_OMIT_LOCALTIME=1 -DSQLITE_ENABLE_MATH_FUNCTIONS -DSQLITE_ENABLE_PERCENTILE \ -DSQLITE_CDECL=__cdecl -DSQLITE_APICALL=__stdcall -DSQLITE_CALLBACK=__stdcall \ -DSQLITE_SYSAPI=WINAPI -D__WINE_PE_BUILD -target aarch64-windows -fuse-ld=lld --no-default-config \ -fno-strict-aliasing -Wno-microsoft-enum-forward-reference -ffunction-sections \ -ffp-exception-behavior=maytrap -gdwarf-4 -g -O2 ..../libs/sqlite3/sqlite3.c:30712:3: error: call to undeclared library function '_ReadWriteBarrier' with type 'void (void)'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration] _ReadWriteBarrier(); ^ .../src/libs/sqlite3/sqlite3.c:30712:3: note: include the header <intrin.h> or explicitly provide a declaration for '_ReadWriteBarrier' 1 error generated. ``` Clang supports the GCC __sync_synchronize() builtin, so use that path for clang as well. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10936
From: Twaik Yont <9674930+twaik@users.noreply.github.com> When building sqlite3 for PE with clang, MSVC_VERSION may select the _ReadWriteBarrier() path, but the intrinsic is not declared in this translation unit. Clang supports the GCC __sync_synchronize() builtin, so use that path for clang as well. Signed-off-by: Twaik Yont <9674930+twaik@users.noreply.github.com> --- libs/sqlite3/sqlite3.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libs/sqlite3/sqlite3.c b/libs/sqlite3/sqlite3.c index facea8f6807..7c83edf2646 100644 --- a/libs/sqlite3/sqlite3.c +++ b/libs/sqlite3/sqlite3.c @@ -30706,7 +30706,7 @@ static int SQLITE_APICALL winMutexNotheld(sqlite3_mutex *p){ SQLITE_PRIVATE void SQLITE_APICALL sqlite3MemoryBarrier(void){ #if defined(SQLITE_MEMORY_BARRIER) SQLITE_MEMORY_BARRIER; -#elif defined(__GNUC__) +#elif defined(__GNUC__) || defined(__clang__) __sync_synchronize(); #elif MSVC_VERSION>=1400 _ReadWriteBarrier(); -- GitLab https://gitlab.winehq.org/wine/wine/-/merge_requests/10936
What compiler is that? -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10936#note_140407
On Mon May 18 15:23:46 2026 +0000, Alexandre Julliard wrote:
What compiler is that? https://github.com/mstorsjo/llvm-mingw/releases/download/20230614/llvm-mingw...
-- https://gitlab.winehq.org/wine/wine/-/merge_requests/10936#note_140408
On Mon May 18 15:23:46 2026 +0000, Twaik Yont wrote:
https://github.com/mstorsjo/llvm-mingw/releases/download/20230614/llvm-mingw... You are going to need a more recent version for ARM64 support.
-- https://gitlab.winehq.org/wine/wine/-/merge_requests/10936#note_140409
On Mon May 18 15:31:26 2026 +0000, Alexandre Julliard wrote:
You are going to need a more recent version for ARM64 support. It works fine with aarch64. Wine works almost fine on my tablet and phone, after applying !10569, !10712, !10926. Currently I am experimenting with vulkan. <details> <summary>video</summary>
{width=900 height=538} </details> -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10936#note_140411
On Mon May 18 15:36:06 2026 +0000, Twaik Yont wrote:
It works fine with aarch64. Wine works almost fine on my tablet and phone, after applying !10569, !10712, !10926. Currently I am experimenting with vulkan. <details> <summary>video</summary> {width=900 height=538} </details> I mean, except the barrier thingy.
-- https://gitlab.winehq.org/wine/wine/-/merge_requests/10936#note_140415
On Mon May 18 15:38:05 2026 +0000, Twaik Yont wrote:
I mean, except the barrier thingy. To run interesting apps you'll want arm64ec, which will require a more recent toolchain.
-- https://gitlab.winehq.org/wine/wine/-/merge_requests/10936#note_140417
On Mon May 18 15:52:54 2026 +0000, Alexandre Julliard wrote:
To run interesting apps you'll want arm64ec, which will require a more recent toolchain. Right, but after rebasing my tree on current master this is the only new build failure I hit with this toolchain.
The fix is also quite small: clang supports __sync_synchronize(), so this just makes it use the same path as GCC instead of falling through to the _ReadWriteBarrier() branch. I don't deny that I may have to update the toolchain eventually, but if this older one can keep working for now with such a small fix, I would prefer that. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10936#note_140418
On Mon May 18 16:07:12 2026 +0000, Twaik Yont wrote:
Right, but after rebasing my tree on current master this is the only new build failure I hit with this toolchain. The fix is also quite small: clang supports __sync_synchronize(), so this just makes it use the same path as GCC instead of falling through to the _ReadWriteBarrier() branch. I don't deny that I may have to update the toolchain eventually, but if this older one can keep working for now with such a small fix, I would prefer that. That file is imported from the upstream project so it's better to avoid changing it if we can.
-- https://gitlab.winehq.org/wine/wine/-/merge_requests/10936#note_140424
On Mon May 18 16:18:56 2026 +0000, Alexandre Julliard wrote:
That file is imported from the upstream project so it's better to avoid changing it if we can. Note also that the file is generated with dlls/winsqlite/make_sqlite.py so the fixups / changes, if needed, should go there (or well, otherwise the generator should be dropped but it will probably make library version bump harder). But if up to date Wine does not really support building with clang from 2023 in general it would be great to avoid that ofc.
-- https://gitlab.winehq.org/wine/wine/-/merge_requests/10936#note_140428
On Mon May 18 16:25:34 2026 +0000, Paul Gofman wrote:
Note also that the file is generated with dlls/winsqlite/make_sqlite.py so the fixups / changes, if needed, should go there (or well, otherwise the generator should be dropped but it will probably make library version bump harder). But if up to date Wine does not really support building with clang from 2023 in general it would be great to avoid that ofc. In general (i.e. on x86) clang from 2023 is fine, but on ARM64 we need fairly recent tools.
-- https://gitlab.winehq.org/wine/wine/-/merge_requests/10936#note_140431
On Mon May 18 16:33:36 2026 +0000, Alexandre Julliard wrote:
In general (i.e. on x86) clang from 2023 is fine, but on ARM64 we need fairly recent tools. So, should I close the MR and update to more modern toolchain?
-- https://gitlab.winehq.org/wine/wine/-/merge_requests/10936#note_140435
On Mon May 18 18:24:44 2026 +0000, Twaik Yont wrote:
So, should I close the MR and update to more modern toolchain? Yes, it's not worth the effort to handle old ARM64 toolchains.
-- https://gitlab.winehq.org/wine/wine/-/merge_requests/10936#note_140453
This merge request was closed by Twaik Yont. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10936
On Mon May 18 20:06:51 2026 +0000, Alexandre Julliard wrote:
Yes, it's not worth the effort to handle old ARM64 toolchains. I hit the same issue building on Ubuntu 24.04 aarch64 with system clang-18 (1:18.1.3-1). For what it's worth, the issue also occurs with current distro toolchains, not just older llvm-mingw releases. I worked around it locally by using llvm-mingw-20250513.
As Paul mentioned, I had also prepared a fix in `make_sqlite.py` using `__dmb(_ARM64_BARRIER_ISH)` for the `_M_ARM64` case, keeping `_ReadWriteBarrier()` for x86. But given the preference to avoid patching for older toolchains, just noting this for reference in case it comes up again as more people build Wine on ARM64 Linux distributions. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10936#note_141169
participants (5)
-
Alexandre Julliard (＠julliard) -
Kivanc Gunalp (＠kivancg)
-
Paul Gofman (＠gofman)
-
Twaik Yont
-
Twaik Yont (＠twaik)