Compilation on M2 Mac #3
Comments
|
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
<#3>, or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABNHS4RXDLWKJUIUSQXRNALYB6UONAVCNFSM6AAAAAA6WBC3ECVHI2DSMVQWIX3LMV43ASLTON2WKOZRHE3DQMZXHA3TKNI>.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
|
|
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.
|
|
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. |
|
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
<#3 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABNHS4SILQM32VFK7CJWPWDYB7VMZAVCNFSM6AAAAAA6WBC3ECVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTOOBVG44TKOBYG4>.
You are receiving this because you commented.Message ID:
***@***.***>
|
|
So the compilation proceedure I've been using is to create a
Which returns: After that, I've attached the |
|
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 <target>"
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
<#3 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABNHS4WCCH42EOCTINJRAJLYCCSEJAVCNFSM6AAAAAA6WBC3ECVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTOOBWGYZTCMJUGY>.
You are receiving this because you commented.Message ID:
***@***.***>
|
|
I tried going from scratch again and using
Are these likely to be causing a problem? |
|
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
<#3 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABNHS4RL6BJHQCJSDIUEISDYCDLKZAVCNFSM6AAAAAA6WBC3ECVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTOOBWHE4TENRWGU>.
You are receiving this because you commented.Message ID:
***@***.***>
|
|
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. |
|
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
<#3 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABNHS4VUTS7ZE3FVLZ4ZMULYCDXDZAVCNFSM6AAAAAA6WBC3ECVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTOOBXGE2DQNZVGA>.
You are receiving this because you commented.Message ID:
***@***.***>
|
|
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:
My portaudio installation is from the the current homebrew cask of it, is there an additional step or extra tweak? |
|
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 <portaudio.h> ^~~~~~~~~~~~~
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
<#3 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABNHS4WXUTJQPQ5LDLCQS5TYCSXPPAVCNFSM6AAAAAA6WBC3ECVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTOOJSGA4DAMJWGE>.
You are receiving this because you commented.Message ID:
***@***.***>
|
|
Ok, so Closest matches there are:
and in a sub-folder called |
|
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
<#3 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABNHS4S6J4RNQEKWFV4B6OTYCTFTPAVCNFSM6AAAAAA6WBC3ECVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTOOJSGI2DKNZSG4>.
You are receiving this because you commented.Message ID:
***@***.***>
|
|
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
Without adding it to the latter, I also had to find 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 |
|
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
<#3 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABNHS4SPGMNBDCUWM4W47S3YCTW3JAVCNFSM6AAAAAA6WBC3ECVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTOOJSGQ2DEMBUHA>.
You are receiving this because you commented.Message ID:
***@***.***>
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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:
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
The text was updated successfully, but these errors were encountered: