macos build

[lawendel]

I've already installed both the original dsd master and its rtl branch on my Macbook Air M1 with Monterey, but it would be nice to try for the new bandwidth options introduced with dsd-fme. Trying with the usual build instructions I fail with a

Could NOT find Curses (missing: CURSES_INCLUDE_PATH)

error message. I know Curses is available on MacOS via Homebrew/ncurses, would installing it be a direct solution to my problem or I'd rather modify the INCLUDE path in Cmakelists.txt? Or completely make without Curses?

Thanks!

[lwvmobile]

error message. I know Curses is available on MacOS via Homebrew/ncurses,

Possibly, not sure which packages from homebrew you would need though to be honest, the other hurdle would also be pulse audio, since I added that as a requirement as well, doing away with OSS and PortAudio entirely. I'm assuming all the mac homebrew packages include the dev components for building as well. I don't suppose it can hurt to homebrew install ncurses and pulseaudio and see what happens.

I don't own a mac, so this is one of those things that I can't test out and see for myself.

[lawendel]

Apparently, Pulseaudio is being detected (though I can't tell what happens next!) Brew installs nucurses correctly albeit in keg mode, not directly linked for compilers. Setting ncurses' path variables however is not enough. I see there's an issue with curses/ncurses detection in online literature, but I'm not very proficient (actually not proficient at all) with Cmake and documentation on FindCurses doesn't help me. It should be solvable in principle, because other SDR applications I've built make use of ncurses. Thanks for your input, maybe some other Mac users have found a solution! For the moment I'll stick to dsd rtl branch, for me correct usage is far from trivial...

[lwvmobile]

I honestly have no idea, the only other thing I could think of to try would be to try to build ncurses from the source code first, and then see if it works properly.

https://github.com/mirror/ncurses

If you wanted to try to do a quick mod to the original rtl branch source code, you could make the change mentioned in this issue and do a rebuild if you wanted to try to run it at 12kHz for example.

szechyjs#110

[lawendel]

That sounds promising, I've already experienced the need to build from source, not from brew, with some libraries. Either this or maybe a brew HEAD/link combination. I saw comparchitect's note on defining a 12000 rate instead of 48000, it looks more suitable for DMR. Thanks, again!

[lawendel]

Just wanted to add ncurses detection has been solved with a "-D CMAKE_PREFIX_PATH=" option pointing to the Homebrew install of ncurses 6.3.
As you suspected, however, there IS an issue with PulseAudio:

CMake Warning (dev) at /opt/homebrew/Cellar/cmake/3.24.2/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:438 (message):
  The package name passed to `find_package_handle_standard_args` (PulseAudio)
  does not match the name of the calling package (PULSEAUDIO).  This can lead
  to problems in calling code that expects `find_package` result variables
  (e.g., `_FOUND`) to follow a certain pattern.
Call Stack (most recent call first):
  cmake/FindPULSEAUDIO.cmake:44 (find_package_handle_standard_args)
  CMakeLists.txt:17 (find_package)
This warning is for project developers.  Use -Wno-dev to suppress it.

-- Could NOT find PulseAudio (missing: PULSEAUDIO_MAINLOOP_LIBRARY) (found version "14.2")

But I refuse giving up too soon!

[lwvmobile]

One step forward. Could be the same or similar fix to what you had to do with ncurses to make that work as well. Another thing to try in the cmake/FindPULSEAUDIO.cmake file is to try to hard code the path to the pulseaudio.h and simple.h to where they are stored on your directory structure here:

find_path(PULSEAUDIO_INCLUDE_DIR NAMES pulse/pulseaudio.h pulse/simple.h
                                 PATHS ${PC_PULSEAUDIO_INCLUDEDIR} ${PC_PULSEAUDIO_INCLUDE_DIRS})

[lwvmobile]

@lawendel Wanted to get back in touch with you, was working on a new 'lite' version based on the current main branch, and was wondering on the other versions that you've used (szechy with rtl support) what audio output method do you use, do you use the OSS output method, or do you use port audio output? Also, wasn't entirely sure which internal method I needed, dsd originally made a check against this line, I have no idea if current macs (or any older macs) needed this include or not.

4g5xdt3c

#if defined(BSD) && !defined(__APPLE__)
#include <sys/soundcard.h>
#endif

What full command do you give to the szenchy rtl branch to get it going with rtl input and audio output on your m1 mac?

[lawendel]

Sorry for this @lwvmobile, I've missed your comment's notification and I've just read this message. I'll be back with a feedback on this in a while. Lately, work has been keeping me off my Mac porting experiments!
Thanks for keeping the issue in mind.

[fuyu]

Excuse me hijacking the ticket as I'm too trying to build the project on MacOS. It seems like I overcome the issues with dependencies but I bumped into the following errors during make command:

/dsd-fme/src/dmr_bs.c:57:3: error: function definition is not allowed here
  {
  ^
/dsd-fme/src/dmr_bs.c:267:28: error: call to undeclared function 'getTime'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
    fprintf (stderr,"%s ", getTime());

To me it seems like I either need to use a different version of gcc or provide a flag. @lwvmobile could you please give a hint on what exactly could be the cause?

The version I'm trying with:

$ gcc --version                                                                                                               
Apple clang version 14.0.3 (clang-1403.0.22.14.1)
Target: arm64-apple-darwin22.6.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin

[lwvmobile]

I honestly don't know what to tell you regarding this, but the best I can tell is that Apple Clang (or maybe any Clang) doesn't like implicit function declarations, so if you could find a way to switch to gcc instead of Clang, then it might work for you, but since I don't have any Apply stuff to test on or figure out (which would be an entirely new learning experience trying to figure that out to begin with) I really wouldn't know what to advise you on how to go about doing that, assuming that is the only thing needed to figure it out. It might also heavily rely on what kind of hardware you have (Intel vs M1, etc, assuming M1 because its arm64??)