Re: FTBFS on sparc: __sync_test_and_add_4
On Wed, 2009-04-29 at 14:11 +1000, Felipe Sateler wrote:
> Hi sparc porters. I'm writing to ask for your assistance on a FTBFS on
> my package csound on sparc. The build log is here. The failure is
> the following:
> > libCsoundAC.so.5.2: undefined reference to `__sync_fetch_and_add_4'
> Csound uses __sync_lock_test_and_set for spinlocks,
Given that pthread_spinlock is in one of the POSIX extensions, is there
a good reason you are building your own synchronisation primatives?
> and tests for
> their existence at build time to use them.
This is the following test?
Checking for __sync_lock_test_and_set((int32_t *)0, 0) in C library m...
found sync lock
> Sparc's gcc apparently
> provides said function, since the test succeeds, but I'm getting the
> above failure (note that __sync_fetch_and_add_4 is nowhere mentioned
> in the csound sources).
May it come from a supporting library? Which synchronisation primatives do you use?
> What is a possible cause for this? I don't have access to sparc
> machines so I'm kind of unsure what to do here. Note that csound uses
> -Wl,--as-needed for most of its libraries.
> Please CC me on replies, I'm not suscribed.
OK, __sync_* aren't part of the C library as such, they are GCC
built-ins that give a (psuedo) machine independant wrapper around atomic
instructions. Unfortunately which atomic ops machines implement varies
greatly. The GCC interface is kind of written assuming the union of x86
and Alpha, in many cases unavailable atomic ops can be emulated.
SPARC, certainly early revisions, are very short on atomic operations.
I'll have to check an architecture manual but IIRC V7 only has test and
set and atomic swap, V9 / V8+ is needed to get compare and swap. I
believe the current default is for Debian to target V8. This would be
sufficient to pass a check for test_and_set, but not enough to give
fetch_and_add, which you'd need compare and swap to emulated.
I'd try to isolate which section of code you needs these instructions,
see if there is a more portable way of writing that section of code (if
it is a library it may be necessary to bug report this back) and failing
all else you may want to try setting the architecture to V8+, but be
aware this may have portability issues, plus I'm not entirely sure what
the current policy on shipping V8+ packages is; it may be necessary to
produce two versions, one V8 and one V8+