CDPv8 and M1

[Natasha]

I'm trying to install on an M1 and see the thread from 2022 stopped.

Is there an M1 beta around?

The 7.1 version says "failed installation", I guess because its 32bit. I see on GitHub there is version 8 source code. Has anyone tried compiling this for M1? Happy to test a beta rather than starting from scratch with Apple's new horrible Xcode!

I'm happy with just the individual programs without the graphical interfaces (old school CDP'er!).

I'm running the following:
Hardware - M1 Ultra
OS - Ventura 13.2.1

Natasha Barrett

[rwdobson]

Hi Natasha,

yes indeed, we are very close to being able to announce Release 8 along with full packages for Mac and PC. We have had several reports of success building CDP (including R8) from source. We have made a lot of code updates recently, mostly to eliminate compiler warnings, but catching a few minor bugs as well.  At present, the Github resource is still to be regarded technically as "Beta".

With regard to existing installers (v 7.1.1), again we have had good reports of successes there on M1. Being a download and not having an official Apple certificate, the "Gatekeeper" system prevents opening, but there is a standard solution which we have documented.

I have just posted the latest beta build of the CDP programs for Mac here:

http://www.rwdobson.com/MacR8-13-03-23.zip

It is compiled for Intel machines (unfortunately CDP does not have access to an M1-based Mac), but I am assured that the new M1 "rosetta" system works as expected and all the programs will run.  Documentation preparation is at an advanced stage, but not ready for release yet. We will publish it at the same time we announce the full CDPR8 release.

Richard Dobson

[Natasha]

Wonderful. Downloaded and out of quarantine!

[MCal27]

Hi Richard, The link above for V8 beta doesn't work now. Is it possible to post a new link please? Would love to try it on my M1 pro Mac

Thanks, Alan

[cordelia]

Hi,
is there any news from it?

[pmj]

I had a stab at compiling CDPv8 on an M2 Mac Mini and got as far as the final "make" command without any problem but then got:

In file included from /Users/pmj/CDP8/dev/newsfsys/sfsys.c:157:
/Users/pmj/CDP8/dev/newsfsys/sffuncs.h:203:2: error: "Unknown byte order for this processor"
#error  "Unknown byte order for this processor"
^
/Users/pmj/CDP8/dev/newsfsys/sffuncs.h:207:2: error: "Internal: can't be both MSB and LSB"
#error  "Internal: can't be both MSB and LSB"
^
2 errors generated.
make[2]: *** [dev/newsfsys/CMakeFiles/sfsys.dir/sfsys.c.o] Error 1
make[1]: *** [dev/newsfsys/CMakeFiles/sfsys.dir/all] Error 2
make: *** [all] Error 2

If anyone knows how to get past this I'm happy to try again.

[Seán]

Hello pmj,

I tried building last Spring on an M2 and this was the first problem I encountered. This was luckily a simple fix. In 'ssfunc.h', there is an if/then clause somewhere which is referring to the byte order for the processor. You need to change this to force the byte order to 'LSBFIRST' for the ARM processor.

This got me past this error but the next problem was with portaudio. I was unable to install portaudio on the M2. Well, I thought I did, it seemed to build fine, but I could not point the CDP make files towards it no matter what I tried. If you manage to get the portaudio portion working I would love to know how! There is no Homebrew etc for portaudio as far as I know.

All the best,
Seán

[pmj]

Hi Seán

I've had a look at 'ssfunc.h' and there's this section:

#define MSBFIRST        (1)
#define LSBFIRST        (1)
/* RWD extended set of symbols ! Now works for Mac universal Binary build */
#if defined(__I86__) || defined(_X86_) || defined(__x86_64) || defined(__i386__) || defined(__i486__) || defined(_IBMR2)
#undef MSBFIRST
#elif defined(M68000) || defined(__sgi) || defined (__POWERPC__)
#undef LSBFIRST
#else
#error  "Unknown byte order for this processor"
#endif

#if defined(MSBFIRST) && defined(LSBFIRST)
#error  "Internal: can't be both MSB and LSB"
#endif

What would I need to change that to (if that's the correct bit...?)

There is a homebrew for portaudio here:

https://formulae.brew.sh/formula/portaudio

[rwdobson]

The messages here have all pointed to the correct place in the code, sffuncs.h. This issue in fact raises an interesting "strategic" question which I have been pondering: are big-endian platforms now effectively dead? if so, all that code can be eliminated (including a lot of dependent code in sfsys) and let it assume the host machine will always be little-endian. This would be an problem however if anyone hopes to build for a cherished PowerPC machine such as an old G5.

In the meantime, the solution needs to use a symbol that is also used in the relevant CMakeLists.txt file. On the Mac the simplest solution would be to add || defined(MAC) in the sffuncs.h line, as that is used in all the CMakeLists.txt files throughout CDP. If supporting big-endian platforms remains important, some new symbol can be defined such as __ARM64, to be used in both places.

Those building CDP8 from source from Github may like to consider posting questions such as this (which are not about "installation" issues as such) directly via the Github message system. I will receive these immediately through email, and can respond accordingly. This  doesn't require anyone to be "registered" as a developer. I have already answered quite a few queries this way.

[Seán]

Hi all,

Apologies for the delay pmj. You are correct that is exactly the bit of ssfunc.h throwing the error. You could just comment out or delete the if function;


##################

#define MSBFIRST        (1)
#define LSBFIRST        (1)

/* RWD extended set of symbols ! Now works for Mac universal Binary build */
/*#if defined(__I86__) || defined(_X86_) || defined(__x86_64) || defined(__i386__) || defined(__i486__) || defined(_IBMR2)/*
/*#undef MSBFIRST/*
/*#elif defined(M68000) || defined(__sgi) || defined (__POWERPC__)/*
/*#undef LSBFIRST/*
/*#else/*
/*#error  "Unknown byte order for this processor"/*
/*#endif/*

#if defined(MSBFIRST) && defined(LSBFIRST)
#error  "Internal: can't be both MSB and LSB"
#endif

##################

Basically from here in the code you should have defined LSBFIRST as the byte order. I dont have access to the same machine I was trying this on at the moment, but I am 90% sure that is what I did.

#define LSBFIRST        (1)

-on it s own would do it too

Richard â€"me and Nando were talking when we trying to figure this out and I guess it essentially is dead? But there definitely could be some Power PC users still out there still given the flexibility of CDP and the hard to reach places you might find users? Thanks Richard for the invitation to communicate directly on Git!

pmj the new releases should work out of the box for you on M2 also? With a regular installation.

All the best,
S