Small compile error fix


#1

I thought a give it a try and start working on a gui less JUCE build on android. I'll report the changes I had to make and hope they will get included in the tip.

As reported by Andrew J in a previous post:

in juce_StandardHeader.h - change the include for <sys/atomics.h> to <stdatomic.h>
in juce_core.cpp - move the include for <sys/timeb.h> inside the "#if ! JUCE_ANDROID" statement

In juce_android_SystemStats.cpp, line 281, sysconf returns a long, therefore this will give a compile time error:

numCpus = jmax (1, sysconf (_SC_NPROCESSORS_ONLN));

A very easy fix:

numCpus = jmax (1L, sysconf (_SC_NPROCESSORS_ONLN));

I am sure there will be a few more before things start flying ;-)


#2

Hmmm. Did the base class change?

modules/juce_audio_devices/native/juce_android_OpenSL.cpp:168:10: error: 'bool juce::OpenSLAudioIODevice::setAudioPreprocessingEnabled(bool)' marked override, but does not override

#3

Nope.. that override looks correct to me. Have you got a header file version mix-up or something?


#4

Right, this one was my bad.

I fixed my setup and double checked the other issues which are not my error as far as I can see ;-)


#5

Actually the fix for stdatomics.h reported above needs to be:

in juce_StandardHeader.h change the sys/stdatomics.h include to this:

 #ifdef __cplusplus
  #include <atomic>
 #else
  #include <stdatomic.h>
 #endif

You can read up about the reasons here: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60932


#6

Ok, but we can safely assume that this will always be C++, not C, so the #if is unnecessary, right?

And to clarify: what you're suggesting is to replace the current

 #include <sys/atomics.h>

with

 #include <atomic>

?


#7

You are right. We can assume that this will always be C++ which brings this change down to a simple replacement of

#include <sys/atomics.h> to #include <atomic>

This is working for me using the Android NDK R10d, Toolchain 4.9.


#8

Thanks. That's updated now.


#9

Hi

Is it correct, that only one of the three issues mentioned here has been fixed? The issue with jmax in juce_android_SystemStats.cpp and the issue in juce_core.cpp still seems to be present in the latest Juce verison. 

Best regards

John


#10

No.. it's all fixed, I think (?)


#11

Hmmm, I am not sure it is. I had to make the following modification in juce_android_systemStats.cpp in order to avoid compiler errors:

numCpus = jmax ((int)1, (int) sysconf (_SC_NPROCESSORS_ONLN));

Otherwise the compiler treated the first argument as a long int and was not able to find a version of jmax that fits.

Changing 1 to 1L did not work for me.

I also had to move "#include <sys/timeb.h>" into the #if ! JUCE_ANDOID statement in juce_core.cpp as stated at the top of this thread, to get it to build.

So unless I have a Juce version mixup, I dont think it has been fixed?

I have the latest Android SDK and NDK

Best regards

John


#12

The cast to int seems very odd to me - it doesn't seem to be needed when I build, and if you search the codebase for the string "jmax (1, " then you'll see that there are dozens of places where I've compared an int with 1 without casting, so am puzzled by why only you would have touble with it, and only in this one place! But ok, I'll add the cast if it helps on your system!


#13

Hi Jules

I agree, that it is odd. We compiled the code on another system running linux, and ran into the same issue. The cast fixed it on both systems.

Thank you for your help.

Best regards

John


#14

sysconf returns a long. Values like "1" are treated by the compiler as an int, and I suppose that on 64 bit systems, since int != long, that is why the cast is needed.


#15

I know, but in my code the second parameter was already being cast to int, i.e.

    numCpus = jmax (1, (int) sysconf (_SC_NPROCESSORS_ONLN));

..and apparently even that didn't work, which seems extremely suspicious to me!