[MacPorts] #73371: selfupdate to 2.11.6 fails with symbol(s) not found on OS X 10.7.5

[MacPorts]

#73371: selfupdate to 2.11.6 fails with symbol(s) not found on OS X 10.7.5
---------------------+--------------------
  Reporter:  dkav    |      Owner:  (none)
      Type:  defect  |     Status:  new
  Priority:  Normal  |  Milestone:
 Component:  base    |    Version:  2.11.6
Resolution:          |   Keywords:
      Port:          |
---------------------+--------------------

Comment (by ryandesign):

 I agree updating the CLT might help, since we had no problem building this
 on our Mac OS X 10.7 buildbot worker which uses the latest Xcode and CLT.
 However this compile failure suggests a bug in sqlite3.

 sqlite3 is bundled with tcl which is bundled with MacPorts. Specifically
 MacPorts 2.11.6 bundles tcl 8.6.16 which bundles sqlite3 3.47.2.

 In sqlite3 3.47.3, sqlite3.c (an [https://sqlite.org/amalgamation.html
 amalgamation] of all sqlite3 source files) says:

 {{{#!c
 /*
 ** A few places in the code require atomic load/store of aligned
 ** integer values.
 */
 #ifndef __has_extension
 # define __has_extension(x) 0     /* compatibility with non-clang
 compilers */
 #endif
 #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
 # define SQLITE_ATOMIC_INTRINSICS 0
 # define AtomicLoad(PTR)       (*(PTR))
 # define AtomicStore(PTR,VAL)  (*(PTR) = (VAL))
 #endif
 }}}

 This is unchanged in the latest version available today, sqlite3 3.51.2.

 The error tells us `GCC_VERSION>=4007000 || __has_extension(c_atomic)`
 must have been true. The gcc version that clang pretends to be is always
 4.2.1, so `__has_extension(c_atomic)` must be true.

 [https://sqlite.org/forum/forumpost/b84facfe0df9352000810f873b627dc63dda6d0dbd842f7cc79feb8f6e7d33e9
 Other have complained] of sqlite3 failing to compile due to this with
 other compilers, claiming that `__atomic_load_n` and `__atomic_store_n`
 are specific to gcc and should not be used with other compilers. Maybe
 clang later added those for gcc compatibility but didn't have them when it
 initially implemented the `c_atomic` extension.

 [https://stackoverflow.com/a/57488028 This Stack Overflow answer] says "in
 application code you should use the standard functions provided by
 <stdatomic.h> not compiler builtins."

 Previously
 [https://sqlite.org/forum/forumpost/74fd4e52e02f1db18a47404f2b47a4fa83e73ae4e63ee29ffd1c78e7dff95c3f
 this patch was proposed] to use <stdatomic.h> when available. We know that
 <stdatomic.h> is not available until about Apple Clang 703 so I don't
 think that would help this situation on Mac OS X 10.7 which tops out at
 Apple Clang 425.

-- 
Ticket URL: <https://trac.macports.org/ticket/73371#comment:4>
MacPorts <https://www.macports.org/>
Ports system for macOS