Added macOS build capability

[elvis-epx]

No description provided.

[mylesagray]

Tested on Mojave 10.14.2.

For anyone that comes across this PR - it doesn't totally solve the build problem, at least not on the above OS version.

For some reason there are some missing type definitions, the one the compiler always crashed on for me was le64toh with error output as below:

make DARWIN=yes
cc -DMODES_DUMP1090_VERSION=\"\" -DMODES_DUMP1090_VARIANT=\"dump1090-fa\" -DENABLE_RTLSDR -DENABLE_BLADERF -std=c11 -O2 -g -Wall -Werror -W -D_DEFAULT_SOURCE -I/usr/local/Cellar/librtlsdr/0.6.0/include/ -I/usr/local/Cellar/libusb/1.0.22/include/libusb-1.0 -I/usr/local/Cellar/libbladerf/2018.08/include/ -DPOSIX_MACH_TIMING -c sdr_bladerf.c -o sdr_bladerf.o
sdr_bladerf.c:358:39: error: implicit declaration of function 'le64toh' is invalid in C99 [-Werror,-Wimplicit-function-declaration]
        uint64_t metadata_timestamp = le64toh(*(uint64_t*)(header + 4));
                                      ^
1 error generated.
make: *** [sdr_bladerf.o] Error 1

I resolved it by re-defining the type at the top of sdr_bladerf.c as so (per this blog):

#ifdef __APPLE__
#include <machine/endian.h>
#include <libkern/OSByteOrder.h>

#define htobe16(x) OSSwapHostToBigInt16(x)
#define htole16(x) OSSwapHostToLittleInt16(x)
#define be16toh(x) OSSwapBigToHostInt16(x)
#define le16toh(x) OSSwapLittleToHostInt16(x)

#define htobe32(x) OSSwapHostToBigInt32(x)
#define htole32(x) OSSwapHostToLittleInt32(x)
#define be32toh(x) OSSwapBigToHostInt32(x)
#define le32toh(x) OSSwapLittleToHostInt32(x)

#define htobe64(x) OSSwapHostToBigInt64(x)
#define htole64(x) OSSwapHostToLittleInt64(x)
#define be64toh(x) OSSwapBigToHostInt64(x)
#define le64toh(x) OSSwapLittleToHostInt64(x)

#define __BIG_ENDIAN BIG_ENDIAN
#define __LITTLE_ENDIAN LITTLE_ENDIAN
#define __BYTE_ORDER BYTE_ORDER
#endif

Myles

[bbss]

Thanks, got this to work thanks to the branch+tips but ran into a little more trouble.

Had to follow instructions here:
https://github.com/Nuand/bladeRF/wiki/Getting-started%3A-Mac-OSX

Added the directory PKG_CONFIG_PATH=/opt/local/lib/pkgconfig/ before the make.

Added the snippet of @mylesagray

But still ran into trouble make-ing dump1090, I think it's because my gcc is 4.2.x and got a type error which actually was only a warning. Removing the -Werror flag in the Makefile made the build succeed.

-CFLAGS += $(DIALECT) -O2 -g -Wall -Werror -W -D_DEFAULT_SOURCE
+CFLAGS += $(DIALECT) -O2 -g -Wall -W -D_DEFAULT_SOURCE

Then I ran into an issue when trying to run the dump1090 binary with the blade lib not being available, had to:

otool -L dump1090
;;change the @rpath path:
dump1090:
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1252.200.5)
	/usr/local/opt/librtlsdr/lib/librtlsdr.0.dylib (compatibility version 0.0.0, current version 0.6.0)
	/usr/local/opt/libusb/lib/libusb-1.0.0.dylib (compatibility version 2.0.0, current version 2.0.0)
	@rpath/libbladeRF.2.dylib (compatibility version 2.0.0, current version 0.0.0)
	/usr/lib/libncurses.5.4.dylib (compatibility version 5.4.0, current version 5.4.0)

;;by using install_name_tool
install_name_tool -change @rpath/libbladeRF.2.dylib /opt/local/lib/libbladeRF.2.dylib dump1090

After that running dump1090 works for me!

[mikeage]

Running without bladerf (make BLADERF=no DARWIN=yes) worked perfectly for me with no extra steps. Nice work!

[mikenor]

I think this is not a very good way of doing it. Dump1090 does not need MacOS support "added" per se - it already has it. But it's apparently been neglected and fallen into disrepair.

Having a compile-time parameter DARWIN=yes seems inelegant, as that ought to be automatically detectable. Dump1090's Makefile used to automatically detect Darwin or Linux but that was removed by commit bef563b. It would probably be doable to bring back.

And Dump1090 already has code in the compat/ folder that implements the timing functions needed for MacOS compatibility. Rather than just throwing in a different implementation from a third party, it might be worth getting the existing code working again. My understanding is that newer versions of MacOS do provide "some" of the functionality, so the compat code probably needs to be updated to not duplicate those functions on newer OS versions.

I tried building the last commit prior to the Makefile being clobbered but my MacOS is too new. It barfs about compat/clock_nanosleep.h redefining stuff that's already defined in 10.14's header files. I don't think it would take much to fix.

[mikenor]

Fyi I opened pull request #38 which fixes Mac compatibility by using the already-existing compatibility code.