Ryan Schmidt sqlite-2012a at ryandesign.com wrote:
Hello, I'm writing on behalf of the MacPorts package management
system. Our users are having trouble compiling sqlite 3.7.10 on
OS X 10.4, both on PowerPC and on Intel. 3.7.9 compiled fine.
The error is:
ld: Undefined symbols:
_OSAtomicCompareAndSwapPtrBarrier
The complete log is attached to our bug report:
https://trac.macports.org/ticket/32930
Thanks for any help you can provide.
Here are a few observations and deductions that may help you narrow your
search.
OSAtomicCompareAndSwapPtrBarrier(...) is implemented in the so-called
'Standard C Library' on BSD, hence on modern Apple platforms. It is not
declared or #defined anywhere in the published SQlite3 source, only
used, under an #ifdef __APPLE__ protected section of code. This section
did not appear in a form calling OSAtomicCompareAndSwapPtrBarrier in
SQlite3 v3.7.9, but v3.7.10 has such a call. (You surely surmised this;
I just mention it to support some reasoning below.) It appears to be
declared once libkern/OSAtomic.h has been #included. Older versions of
OSAtomic have varying names for very similar functions, such as
OSCompareAndSwapPtr(...) with the same signature.
Here is something that I proffer more tentatively:
The actual declaration appears in a file listed at
http://www.opensource.apple.com/source/CF/CF-635/CoreFoundation_Prefix.h
which has a very strange feature. Instead of the usual bracketing reading
#ifdef __cplusplus
extern "C" {
#endif
the conditional reads
#if DEPLOYMENT_TARGET_WINDOWS && defined(__cplusplus)
. This suggests to me that the definition itself, (the one whose
address must be found by ld to resolve references), may have a name that
is decorated per one of the various C++ schemes, when built for a
platform for which DEPLOYMENT_TARGET_WINDOWS does not get #define'd.
This would cause the link failure you see. The SQLite code, compiled as
C, references the barely decorated name, (with just the leading '_'),
producing the reference that is not resolved, whereas the library, if
compiled as C++, may have exposed its definition with the more ornate
name decoration which encodes the signature.
You could do a little work with nm and grep, looking for where
'OSAtomicCompareAndSwapPtrBarrier' is exposed, either as a definition or
a reference. As soon as you find such, you will see whether it is
C++-decorated or not.
Of course, the problem may be as simple as not having enough libraries
in your link step. That same "nm | grep" effort will tell you what
additional library is needed, (if that will solve the problem).
Given the evolving nature of the synchronization primitives on the
platform, you may be suffering from linking against too-dated libraries.
The "nm $obj | grep OSAtomicCompareAndSwapPtrBarrier" effort should
also uncover that. (If you find the library with the non-Barrier forms
of those primitives, or the older OSCompareAndSwapPtr, but missing
OSAtomicCompareAndSwapPtrBarrier, that would be a strong clue that the
missing entry point is truly missing among the set of libraries you had
hoped to use.)
Good luck,
--
Larry Brasfield
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
