SQLite3 not compiling with non-GCC compilers
(1) By markstz on 2022-05-13 09:53:02 [source]
In the source for 3.38.05 is this definition:
#if GCC_VERSION>=4007000 || __has_extension(c_atomic)
# define SQLITE_ATOMIC_INTRINSICS 1
# define AtomicLoad(PTR) __atomic_load_n((PTR),__ATOMIC_RELAXED)
# define AtomicStore(PTR,VAL) __atomic_store_n((PTR),(VAL),__ATOMIC_RELAXED)
#else
These definitions get enabled for any C compiler that supports the "c_atomic" extension, but the "__atomic_load_n"/"__atomic_store_n" functions are GCC-specific. They are not part of C11/C18, which has "atomic_load"/"atomic_store" functions instead.
The compiler I'm using is the IAR compiler, which has the c_atomic extension but only implements the C11 functions, so it won't compile SQLite.
Please can SQLite be fixed to either use the C11 names or only use GCC-specific functions when compiled with GCC?
(2) By markstz on 2023-01-09 14:01:24 in reply to 1 [link] [source]
This error is still present in 3.40.1.
(3) By Richard Hipp (drh) on 2023-01-09 14:40:12 in reply to 2 [link] [source]
The only compilers I have at hand are various versions of GCC, CLANG, and MSVC. They all work fine with the code as written. What compiler(s) do you recommend that we add to our testing repertoire in order to find these kinds of issues, and to validate any fix that we might happen to apply?
(4) By Warren Young (wyoung) on 2023-01-09 17:47:54 in reply to 3 [link] [source]
The original post references "IAR," meaning this cross-compiler suite for embedded systems.
They're expen$$$ive. If there's a free way to add them to a testing process, I'm not aware of it.
(5.1) By markstz on 2023-10-11 08:01:49 edited from 5.0 in reply to 4 [link] [source]
Crazy idea - you could just stop calling GCC-specific functions when non-GCC compilers are used?
We're still having to patch SQLite locally in order to make it build.
(6) By Max (Maxulite) on 2023-10-11 12:17:57 in reply to 5.1 [link] [source]
As a suggestion for your original issue. Can you just provide some glue lib with compatible names for the linker? I'm not familiar with your toolchain, less familiar with c toolchains in general, but for object pascal/delphi/fpc static linking it's trivial. For instance, for plenty of required symbols (easily linked if vc runtime is provided), I avoid this dependency by having all required standard c symbols in pascal ( including such important ones as _malloc -> {my glue function } -> pascal GetMem ). Sure it breaks the simplicity of the amalgamation compilation but at least you will be able to avoid patching every time.