Atomics not compiling - __sync_


#1

It looks like the:

#elif JUCE_GCC to JUCE_LINUX

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?

Edit - jucedemo won’t compile here either.

Bruce


#2

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.


#3

Sorry, I didn’t say, but this thread is in the Linux forum! I’m on Arch Linux, a system that has always been fine compiling Juce.

Bruce


#4

Doh, sorry! It all compiles fine on my linux installation - you’re not still on gcc3, are you?


#5

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?

Bruce


#6

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)


#7

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?

Bruce


#8

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?


#9

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.

Bruce


#10

Have you tried the newest demo makefile? I changed the way it’s generated last week.


#11

I got the tip a few hours ago. I added an echo to see what depflags was, and it was just md, or something. Adding i486 let it build.

The problem is probably in my system, but the answers not evident. A GCC reinstall didn’t help.

Anyway, the new Atomics mean Linux builds must be 486 and later. I hope that doesn’t make ARM Impossible.

Bruce


#12

I checked my linux machine, and my TARGET_ARCH is also blank, although it all works happily.

Maybe adding this at the start of the makefile:

ifeq ($(TARGET_ARCH),) TARGET_ARCH := -march=native endif

?


#13

There is no atomic instruction in i486!

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.


#14

That’s why I suggested “arch=native”

Did my suggestion work for you, Bruce?


#15

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.


#16

I haven’t had a chance to try yet, sorry, I will. Busy Friday and an actual weekend.

My real question is what got mucked up on my system that it doesn’t default to arch=native and how to fix that.

But I’ll try the native arch add asap.

Bruce


#17

Sorry for the big delay - yes, this works. I need it at the start of JUCE.make when I’m using dynamic libs, probably also in demo etc.

Sorry about my f**ed up system :oops: Thanks for finding a fix.

Bruce


#18

Well, hold on. The fancy ifeq version failed at linking - ar said it was trying to link it, and of course it doesn’t exist.

My:

DEPFLAGS += “-march=native”

does work though. Whew.

Bruce


#19

Ok, by the way, never could find what was messing up the compiler, but I did a rebuild on that machine and it seems fine now.

Seems like a check might not be a bad idea though - that arch is set, and set high enough to make the atomics.

Bruce