El 29/04/09 22:28 Martin escribió:
> 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[1]. 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,
>
> <unhelpful pedantry>
> Given that pthread_spinlock is in one of the POSIX extensions, is there
> a good reason you are building your own synchronisation primatives?
> </unhelpful pedantry>
Hmm, not so unhelpful, given that csound already uses pthreads... maybe this
function just escaped upstreams attention. Wouldn't it be slower to use
(shared) library calls instead of gcc builtins?
>
> > 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...
> yes
> found sync lock
Yes. It just builds a .c file calling that function from main and compiles it.
>
> > 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?
felipe@pcfelipe:csound% rgrep __sync *
H/csound.h: while (__sync_lock_test_and_set(spinlock, 1) == 1) { \
H/csound.h: __sync_lock_release(spinlock); \
SConstruct: syncLockTestAndSetFound =
configure.CheckLibWithHeader('m', 'stdint.h', 'C', '__sync_lock_test_and_set((int32_t
*)0, 0);')
felipe@pcfelipe:csound%
>
> > 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.
But I'm not using fetch_and_add... not directly at least.
>
> 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)
How can I go around to do that? I don't have sparc access, and my amd64
binaries have no trace of any __sync functions.
> 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+
I'd prefer disabling multithreading support than providing useless binaries to
some users.
Saludos,
Felipe Sateler
Attachment:
signature.asc
Description: This is a digitally signed message part.