Change that happened when you changed iPhone atomics broke my Linux compile. I’m using Codeblocks and GCC, and I leave the arch blank for the compiler to work it out.
The _sync functions come up as undefined when I compile my final project. I tried to add -march=i486 or i686 as suggested on the web, but that didn’t help. Do I need to change the juce project’s makefile for that?
Edit - maybe not so simple. Changing that one define back didn’t help. I just refreshed from the tip, about a 3 week old version. Nothing changed on the Linux machine since I had working compiles. Could it be something in the makefile?
It should work on mingw - assuming that you’ve not got JUCE_LINUX defined, no inline atomic should be defined at all, and it’ll use the win32 ones specially for mingw in juce_win32_Threads.cpp.
Nope, 4.4.2. --with-tune is ‘generic’ and there’s no default arch though. Can you please do a GCC -v and see if there’s a default architecture set?
I’ve been messing around with adding ARCH=“i486” to the make command, which seems to be the right syntax, but no joy.
I’ve tried with the packaged and remade Make files.
My linux GIT client doesn’t show when I merged, so it’s hard to tell when I last would have clean built, but I looked back and I didn’t do any updates on the computer since it was last building. Any changes to Linux build settings maybe?
I don’t suppose you weren’t using some of the atomics then added use recently? And they maybe didn’t work at all on my system?
I did change it to use those intrinsic atomic ops recently, but they’re supposed to be standard in gcc. Maybe there’s a header file for them on some systems?
(And doing a gcc -v doesn’t show a setting for -arch on my machine)
Not able to get to my Linux machine right now, but I did some reading. They are not linked from libs, but compiler provided. If the build isn’t for the correct CPU, then the compiler doesn’t generate them and it fails at a weird point - not compiler, not really linker.
I tried to change the arch on my builds, but no luck. All I can assume is some random Linux BS did a configure action and ‘broke’ my compiler setup. There’s some real disadvantages to having to build apps yourself using whatever odd build/configure environment that particular Linux group decided is the one and only true way.
As far as I can tell, Apple has one Steve Jobs, but Linux has thousands of them, each of whom knows better than all the others.
I guess it’s GCC re-install time, or something similarly asinine. Unless someone else is seeing this problem?
Yes, the fragmentation of linux is my main headache with it. That’s really frustrating - have you tried grepping your include path to see if there’s a header file with them somewhere?
Ok, some sort of light. My reading said that the atomics were generated by the compiler for you, and they are. It turns out that right now, on my dev system, TARGET_ARCH is blank, so nothing special builds i.e. no atomics.
I set -march in my code, but had trouble setting it in the juce build - apparently both are required. Unable to feel certain I could force Make to use an arch, I hacked the jucedemo makefile with:
DEPFLAGS += “-march=i486”
And got the demo to build again.
So, if nothing else, it looks like the juce makefiles should detect a CPU of at least 486 - now they allow nothing (probably i386).
No-one else hitting this, really? Anyone know what/how I should set my default architecture? I’m on Arch Linux.
Try with a march=athlon or whatever your processor is.
You should try a simple test.c file with few atomic functions like that to make sure your compiler build it.
Yes you’re right. However, I guessed “arch=native” was the default, and in that case, the issue will still exists: he wouldn’t have reported.
I think the small test file idea without any juce stuff would let him check & solve his compiler woes.
