Compilation on M2 Mac

[philjulian]

I saw your recent email via Archer about making some changes to the CMakeLists.Txt and sffuncs.h files in order to assist compilation on an M2 Mac, I still get the following:

In file included from /Users/pmj/CDP8/dev/sfutils/dirsf.c:78:
/Users/pmj/CDP8/dev/sfutils/../newsfsys/sffuncs.h:203:2: error: "Unknown byte order for this processor"
#error  "Unknown byte order for this processor"
 ^
/Users/pmj/CDP8/dev/sfutils/../newsfsys/sffuncs.h:207:2: error: "Internal: can't be both MSB and LSB"
#error  "Internal: can't be both MSB and LSB"
 ^
/Users/pmj/CDP8/dev/sfutils/dirsf.c:170:9: warning: variable 'cded' set but not used [-Wunused-but-set-variable]
    int cded = 0;       /* did we cd? */    
        ^
1 warning and 2 errors generated.
make[2]: *** [dev/sfutils/CMakeFiles/dirsf.dir/dirsf.c.o] Error 1
make[1]: *** [dev/sfutils/CMakeFiles/dirsf.dir/all] Error 2
make: *** [all] Error 2

I've attached the two edited files from the newsfsys folder in case I've put something in the wrong place, apologies if so.

CDP8_Edits.zip

[richarddobson]

Yes, those are correct changes. It sounds like they haven't been picked up by Cmake so that it automatically reconstructs its makefiles. Sometimes it is necessary to delete the file CMakeCache.txt, which forces a rerun of Cmake. The files actually used for the make are buried deep down inside the build directory - you can check the file "flags.cmake" to confirm the new symbol is added. R.

On 30/10/2023 13:36, Phil Julian wrote:

I saw your recent email via Archer about making some changes to the CMakeLists.Txt and sffuncs.h files in order to assist compilation on an M2 Mac, I still get the following:

|In file included from /Users/pmj/CDP8/dev/sfutils/dirsf.c:78: /Users/pmj/CDP8/dev/sfutils/../newsfsys/sffuncs.h:203:2: error: "Unknown byte order for this processor" #error  "Unknown byte order for this processor"  ^ /Users/pmj/CDP8/dev/sfutils/../newsfsys/sffuncs.h:207:2: error: "Internal: can't be both MSB and LSB" #error  "Internal: can't be both MSB and LSB"  ^ /Users/pmj/CDP8/dev/sfutils/dirsf.c:170:9: warning: variable 'cded' set but not used [-Wunused-but-set-variable]     int cded = 0;       / did we cd? /         ^ 1 warning and 2 errors generated. make[2]: [dev/sfutils/CMakeFiles/dirsf.dir/dirsf.c.o] Error 1 make[1]: [dev/sfutils/CMakeFiles/dirsf.dir/all] Error 2 make: *** [all] Error 2 |

I've attached the two edited files from the newsfsys folder in case I've put something in the wrong place, apologies if so.

CDP8_Edits.zip https://github.com/ComposersDesktop/CDP8/files/13205639/CDP8_Edits.zip

— Reply to this email directly, view it on GitHub https://github.com/ComposersDesktop/CDP8/issues/3, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABNHS4RXDLWKJUIUSQXRNALYB6UONAVCNFSM6AAAAAA6WBC3ECVHI2DSMVQWIX3LMV43ASLTON2WKOZRHE3DQMZXHA3TKNI. You are receiving this because you are subscribed to this thread.Message ID: @.***>

[richarddobson]

Except - my mistake - the appropriate symbol for mM/2 CPUs would be __ARM64. :-). R.

On 30/10/2023 14:40, Richard Dobson wrote:

Yes, those are correct changes. It sounds like they haven't been picked up by Cmake so that it automatically reconstructs its makefiles. Sometimes it is necessary to delete the file CMakeCache.txt, which forces a rerun of Cmake. The files actually used for the make are buried deep down inside the build directory - you can check the file "flags.cmake" to confirm the new symbol is added. R.

[philjulian]

Ah yes, I should have spotted that myself... :)

Corrected those and tried a fresh compilation, still no luck I'm afraid. Same errors as before.

[richarddobson]

Then something odd is happening. I have just made the same change here, and it compiles fine. I can only think that there is something different in your setup. You need to check that the files you have edited are actually the files you are using. Did you see messages from Cmake after editing the CMakeLists.txt file and calling make? For example:

-- Building on OSX -- Configuring done -- Generating done

Assuming you are following the usual procedure and running cmake and calling make from the build directory, what do you have in the file 'flags.make'

in the dirctory build/dev/newsfsys/CMakefiles/newsfsys.dir ?

On 30/10/2023 18:17, Phil Julian wrote:

Ah yes, I should have spotted that myself... :)

Corrected those and tried a fresh compilation, still no luck I'm afraid. Same errors as before.

— Reply to this email directly, view it on GitHub https://github.com/ComposersDesktop/CDP8/issues/3#issuecomment-1785795887, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABNHS4SILQM32VFK7CJWPWDYB7VMZAVCNFSM6AAAAAA6WBC3ECVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTOOBVG44TKOBYG4. You are receiving this because you commented.Message ID: @.***>

[philjulian]

So the compilation proceedure I've been using is to create a build directory in CDP8 and from there running:

cmake -G "Unix Makefiles" ..

Which returns:

-- /Users/pmj/CDP8
-- installing to /usr/local
-- building to /Users/pmj/CDP8/NewRelease
-- LIBRARY INSTALL DIR: lib
-- Not using Custom.cmake file.
-- BUILD_BIN_DIR set to 
-- BUILD_LIB_DIR set to /Users/pmj/CDP8/build/lib
-- paprogs to be built
-- Building on OSX
-- Configuring done (0.3s)
-- Generating done (0.6s)
-- Build files have been written to: /Users/pmj/CDP8/build

After that, cmake --build .

I've attached the flags.make file from build/dev/newsfsys/CMakefiles/newsfsys.dir let me know if that sheds any light on anything.

flags.make.zip

[richarddobson]

The only element that is different from my setup is your call to "cmake --build .". I have never used this option, and I can't be sure that it does what is expected. Since Cmake is expressly creating unix makefiles, all one has to do after the initial command " cmake .." in the build directory, is (still in the build directory) to call "make", or "make "

so one can run make for any target - program or library, e.g.:

make sfsys

(of course, when building a program, make will build any library dependencies as necessary)

It may be the build directory contents have got a bit mixed up, so a full fresh cmake run might be best, such as

cmake --fresh ..

On 31/10/2023 07:29, Phil Julian wrote:

So the compilation proceedure I've been using is to create a |build| directory in CDP8 and from there running:

|cmake -G "Unix Makefiles" ..|

Which returns:

|-- /Users/pmj/CDP8 -- installing to /usr/local -- building to /Users/pmj/CDP8/NewRelease -- LIBRARY INSTALL DIR: lib -- Not using Custom.cmake file. -- BUILD_BIN_DIR set to -- BUILD_LIB_DIR set to /Users/pmj/CDP8/build/lib -- paprogs to be built -- Building on OSX -- Configuring done (0.3s) -- Generating done (0.6s) -- Build files have been written to: /Users/pmj/CDP8/build |

After that, |cmake --build .|

I've attached the |flags.make| file from |build/dev/newsfsys/CMakefiles/newsfsys.dir| let me know if that sheds any light on anything.

flags.make.zip https://github.com/ComposersDesktop/CDP8/files/13213315/flags.make.zip

— Reply to this email directly, view it on GitHub https://github.com/ComposersDesktop/CDP8/issues/3#issuecomment-1786631146, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABNHS4WCCH42EOCTINJRAJLYCCSEJAVCNFSM6AAAAAA6WBC3ECVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTOOBWGYZTCMJUGY. You are receiving this because you commented.Message ID: @.***>

[philjulian]

I tried going from scratch again and using cmake .. rather than what I was using with cmake -G "Unix Makefiles" .. and it returns a slightly more verbose set of information which I've attached here, notibly:

-- Looking for io.h - not found -- Looking for values.h - not found -- Looking for winsock.h - not found

Are these likely to be causing a problem?

Terminal Saved Output.txt

[richarddobson]

On The Mac, if one runs cmake --help, one sees that unix makefiles are the default, so there is no need to specify it explicitly.

Those files are standard windows/unix ones, not required on the Mac.

If it seems some older build files are persisting, sometimes to gtet a proper fresh directory tree one has to delete e.g. the whole CMakefiles directory (in newsfsys) before runnign cmake again.

On 31/10/2023 11:04, Phil Julian wrote:

I tried going from scratch again and using |cmake ..| rather than what I was using with `cmake -G "Unix Makefiles" ..' and it returns a slightly more verbose set of information which I've attached here, notibly:

|-- Looking for io.h - not found| |-- Looking for values.h - not found| |-- Looking for winsock.h - not found|

Are these likely to be causing a problem?

Terminal Saved Output.txt https://github.com/ComposersDesktop/CDP8/files/13215471/Terminal.Saved.Output.txt

— Reply to this email directly, view it on GitHub https://github.com/ComposersDesktop/CDP8/issues/3#issuecomment-1786992665, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABNHS4RL6BJHQCJSDIUEISDYCDLKZAVCNFSM6AAAAAA6WBC3ECVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTOOBWHE4TENRWGU. You are receiving this because you commented.Message ID: @.***>

[philjulian]

Deleted the whole CDP8 folder and started from scratch but those same messages are still persisting. It could easily be something within my setup or how cmake is or isn't configured correctly for this. Bit beyond what I know how to unpick.

I'll try again but a bit stuck for now.

[richarddobson]

I have pushed the changes to sfsys to remove handling of Big_endian platforms. This affects sffuncs.h, snd.c and sfsys.c. You will need to run 'git pull' to update your local copy. If you have any existing local edits, you may need to run 'git stash' first. R.

On 31/10/2023 12:44, Phil Julian wrote:

Deleted the whole CDP8 folder and started from scratch but those same messages are still persisting. It could easily be something within my setup or how cmake is or isn't configured correctly for this. Bit beyond what I know how to unpick.

I'll try again but a bit stuck for now.

— Reply to this email directly, view it on GitHub https://github.com/ComposersDesktop/CDP8/issues/3#issuecomment-1787148750, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABNHS4VUTS7ZE3FVLZ4ZMULYCDXDZAVCNFSM6AAAAAA6WBC3ECVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTOOBXGE2DQNZVGA. You are receiving this because you commented.Message ID: @.***>

[philjulian]

Thanks for this, with a fresh clone of the CDP8 repo and running the cmake / make commands as before it gets to 99% complete and throws up:

`/Users/pmj/CDP8/dev/externals/paprogs/listaudevs/devs.c:27:10: fatal error: 'portaudio.h' file not found

include

     ^~~~~~~~~~~~~

1 error generated. make[2]: [dev/externals/paprogs/listaudevs/CMakeFiles/listaudevs.dir/devs.c.o] Error 1 make[1]: [dev/externals/paprogs/listaudevs/CMakeFiles/listaudevs.dir/all] Error 2 make: *** [all] Error 2`

My portaudio installation is from the the current homebrew cask of it, is there an additional step or extra tweak?

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

[richarddobson]

Well, that is the ongoing remaining issue to resolve. The basic question therefore is: where on your system is portaudio.h? We would expect it, if fully installed, to be in /usr/local/include, and the static library similarly in /usr/local/lib. You can use the standard 'locate' command to find all instances. The sources will likely be elsewhere, as decided by homebrew. Of course we need access to the sources for pa_ringbuffer.c. It is enough to pass the path to that in CMakeLists.txt.

These paths therefore need to be specified in the CmakeLists.txt file for each audio program. Normally we rely on the Cmake directive "find_library" to, well, find the library, but we may need to be more specific, especially if homebrew (etc) has put it in an unexpected place. Most directly, we specify include and lib paths in the list of flags to pass to the compiler, using the -I and -L options. R.

On 03/11/2023 09:03, Phil Julian wrote:

Thanks for this, with a fresh clone of the CDP8 repo and running the cmake / make commands as before it gets to 99% complete and throws up:

|/Users/pmj/CDP8/dev/externals/paprogs/listaudevs/devs.c:27:10: fatal error: 'portaudio.h' file not found #include ^~~~~ 1 error generated. make[2]: [dev/externals/paprogs/listaudevs/CMakeFiles/listaudevs.dir/devs.c.o] Error 1 make[1]: [dev/externals/paprogs/listaudevs/CMakeFiles/listaudevs.dir/all] Error 2 make: *** [all] Error 2|

My portaudio installation is from the the current homebrew cask of it, is there an additional step or extra tweak?

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

— Reply to this email directly, view it on GitHub https://github.com/ComposersDesktop/CDP8/issues/3#issuecomment-1792080161, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABNHS4WXUTJQPQ5LDLCQS5TYCSXPPAVCNFSM6AAAAAA6WBC3ECVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTOOJSGA4DAMJWGE. You are receiving this because you commented.Message ID: @.***>

[philjulian]

Ok, so portaudio.h is in usr/local/include but not in /usr/local/lib

Closest matches there are:

libportaudio.a libportaudio.dylib libportaudio.la

and in a sub-folder called pkgconfigis portaudio-2.0.pc

[richarddobson]

That is exactly what we expect. The .h file is the header file, the .a file is the static library to be linked with a program. These paths are provided in the CMakeLists.txt file. However, that currently looks for portaudio.h in the presumed local build directory of portaudio (../portaudio/include).

You may find it works if you add the line in the "if(APPLE)" section:

include_directories (/usr/local/include)

Alternatively, add that path to the generic directive at the bottom, above "in(MINGW"). This is done, for example, in the version for paplay.

Alkthough it is disappointing that Cmake "find_library" doesn't manage to work that out!

Also, remember you can build an individual target using make, to see if any particular CMakeLists.txt file has the right set of commands. e.g:

make paplay make recsf

etc.

On 03/11/2023 11:04, Phil Julian wrote:

Ok, so |portaudio.h| is in |usr/local/include| but not in |/usr/local/lib|

Closest matches there are;

|libportaudio.a libportaudio.dylib libportaudio.la|

and in a sub-folder called |pkgconfig|is `portaudio-2.0.pc'

— Reply to this email directly, view it on GitHub https://github.com/ComposersDesktop/CDP8/issues/3#issuecomment-1792245727, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABNHS4S6J4RNQEKWFV4B6OTYCTFTPAVCNFSM6AAAAAA6WBC3ECVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTOOJSGI2DKNZSG4. You are receiving this because you commented.Message ID: @.***>

[philjulian]

May have had some success here with a couple of tweaks that may or may not be quite correct...

I found I had to add include_directories (/usr/local/include) to these two CMakeLists.txt files:

/Users/pmj/CDP8/dev/newsfsys/CMakeLists.txt as discussed /Users/pmj/CDP8/dev/externals/paprogs/listaudevs/CMakeLists.txt

Without adding it to the latter, paprogs doesn't "see" portaudio.h

I also had to find pa_ringbuffer.h and pa_util.h from the portaudio github (under "common") as these didn't appear to be on my machine anywhere. These were added to the /usr/local/include directory.

I now get to 100% compiled albiet with quite a few warnings along the way. Log of these warnings is attached here in case it's useful.

The NewRelease folder now has 224 compiled tools in it which I assume is the correct number?

Terminal Saved Output.txt

[richarddobson]

There should be no need to add that to the makefile in newsfsys - it does not use portaudio at all, and is a plain library itself. So that puzzles me. The addition for listaudevs is fine, and looks like a simple omission on my part.

I should add that in the "building" text file "pamacbuild.txt" iside /externals, I describe specifically making a local build of portaudio (needed for all platforms, not just the Mac), which automatically provides access to pa_ringbuffer.c etc, and the Cmake makefiles are constructed accordingly. This also means that when/if problems are raised, we know exactly what version/build of portaudio, and directory structure, the user has. Of course if you don't build portaudio manually from source those (internal) files will indeed not appear on your machine. So that as a procedure is insufficient for building the CDP audio programs. Users may well have to adapt makefiles etc to fit their chosen setup.

I see that I may need to edit that file for people assuming to install via homebrew, which I will do in due course. But in principle we do not want to copy portaudio source files manually, especially "private" ones such as pa_ringbuffer.h. So much easier to unpack and build the portaudio sources as described, and point the makefiles accordingly.

Yes, 224 is correct. Our full distribution adds three small optional shell scipts for invoking external tools such as VLC and QuickTime. R.

On 03/11/2023 13:31, Phil Julian wrote:

May have had some success here with a couple of tweaks that may or may not be quite correct...

I found I had to add |include_directories (/usr/local/include)| to these two |CMakeLists.txt| files:

|/Users/pmj/CDP8/dev/newsfsys/CMakeLists.txt| as discussed |/Users/pmj/CDP8/dev/externals/paprogs/listaudevs/CMakeLists.txt|

Without adding it to the latter, |paprogs| doesn't "see" |portaudio.h|

I also had to find |pa_ringbuffer.h| and |pa_util.h| from the portaudio github (under "common") as these didn't appear to be on my machine anywhere. These were added to the |include_directories (/usr/local/include)| directory.

I now get to 100% compiled albiet with quite a few warnings along the way. Log of these warnings is attached here in case it's useful.

The |NewRelease| folder now has 224 compiled tools in it which I assume is the correct number?

— Reply to this email directly, view it on GitHub https://github.com/ComposersDesktop/CDP8/issues/3#issuecomment-1792442048, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABNHS4SPGMNBDCUWM4W47S3YCTW3JAVCNFSM6AAAAAA6WBC3ECVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTOOJSGQ2DEMBUHA. You are receiving this because you commented.Message ID: @.***>