Compiling JUCE under Mandrake 10.1

Just a heads up:

To get JUCE to compile under Mandrake 10.1 I needed to make the following changes:

in juce_linux_SystemStats.cpp I needed to change

if (sched_getaffinity (getpid(), 
                           sizeof (cpu_set_t), 
                           &processAffinity) != sizeof (cpu_set_t))


    if (sched_getaffinity (getpid(), &processAffinity) != sizeof (cpu_set_t))

given the sched.h declaration:

extern int sched_getaffinity (__pid_t __pid, cpu_set_t *__mask) __THROW;

Also, line 140 in juce_linux_threads.cpp:

sched_setaffinity (getpid(), sizeof (cpu_set_t), &affinity);


 sched_setaffinity (getpid(), &affinity);

based on sched.h declaration

extern int sched_setaffinity (__pid_t __pid, __const cpu_set_t *__mask)


(Odd - I use Mandrake 10.1 myself…)

And about 3 other people have just told me the same thing, though I’ve not changed anything lately. I’m unclear about whether the version without the extra parameter is a newer or older version, and all the manpages online show it with the extra param. I’ll look into it a bit more and report back.

Well I checked sched.h on three of the four linux boxes sharing a room with me, and all agree.

That said, all of these machines are upgrades, some of them having started out with Mandrake 8.something, so they may be different to virgin installs.

ok, I did some checking and it seems that the 2-parameter version is the obsolete one.

I think the best bet is for me to fix my use of the SUPPORT_AFFINITIES macro in the juce code so you can properly disable that stuff if it won’t build properly. Then any hard-core people who are actually using it can just get the latest glibc and it’ll work, but if you don’t need it there’s no disadvantage in just disabling it.

Sounds good to me.

I dislike updating glibc unless necessary, cos invariably something breaks.

I got a basic DICOM browser working under linux on Firday, so I’m back using JUCE again. :slight_smile:

What does DICOM stand for??

I guessed some kind of medical imaging cos that’s what valley’s involved with. Quick search seemed to confirm this.

Digital Imaging and Communications in Medicine (DICOM)

ah - gory pictures of people’s internal bits and pieces.


Yeah, we do mainly image processing/regioning research here. In my case the majority of what I do is user interface related.

DICOM is the standard for acquisition, network transmission, and displaying of medical images. IE, radiographs, CT scans, and the like.

And some of them can be a little gory. :frowning: