I think your recent changes to atomics have caused some issues for building juce for iphone 3.1.3 sdk based apps (atomics are not supported by 3.1.3 as you know). Fine for simulator and 3.2 of course. Only a problem in recent git.
Errors when compiling juce_amalgamated.h:
error: there are no arguments to ‘OSAtomicAdd64’ that depend on a template parameter, so a declaration of ‘OSAtomicAdd64’ must be available
error: ‘OSAtomicIncrement64’ was not declared in this scope
I thought I fixed something like that last week… are you using the very latest tip?
Yeah, I think it was me that mentioned problems with atomics last time too (http://www.rawmaterialsoftware.com/viewtopic.php?f=2&t=5423). It was fixed, but I think another round of changes might have kicked something out of joint. Slightly different error now as well, but still related.
Definitely at the current head, just pulled again and got the latest commit from earlier today. I should note that I haven’t updated for a while (vacation), so it might have been changes a while back that broke it (possibly the may 3rd). I can reset to a few different times and find where it breaks if you want.
Ok, thanks, I’ll take a look.
Looks like you made some changes. Compiles now, but still comes up with a runtime error:
JUCE Assertion failure in /Users/aaronleese/juce/amalgamation/…/src/core/juce_Atomic.h, line 165
probably just need to tweak the logic a little in the case of a device.
ah yes, thanks, I’ll make sure it doesn’t test the 64-bit ops on devices where they’re not available.
Looks like you’ve been moving on this, thanks.
The iPhone device atomics tests seem to be working fine now.
but … I have a new linker errors for ppc architecture:
“___sync_val_compare_and_swap_8”, referenced from:
void juce::juce_testAtomicType(unsigned long long)in JuceLibraryCode1.o
ok, that’s surprising - does this tweak to juce_Atomics.h, line 155 sort it out?
#if (JUCE_IPHONE && (__IPHONE_OS_VERSION_MIN_REQUIRED < __IPHONE_3_2 || ! defined (__IPHONE_3_2))) \
|| (JUCE_MAC && (JUCE_PPC || __GNUC__ < 4 || (__GNUC__ == 4 && __GNUC_MINOR__ < 2)))
That seems to do the trick alright. Thanks.
Hmmmm … So, not sure that this is the same problem, but ever since fixing atomics for the device, I seem to have an issue with the simulator.
It craps out in /audio_sources/dsp/juce_AudioSampleBuffer.h when trying a *getSampleData on the buffer.
I have a feeling this is something to do with atomics (would we have disabled them here with the previous command, but now the dsp/simulator wants to use atomics where the actual dsp/device doesn’t ?).
Not sure, could be totally unrelated even. Let me know what you think.
How should I try to reproduce the problem?
Aha … nevermind.
My own typo on this one. I think you’ve got these all ironed out.
Thanks as always.
