Does not compile on macOS 10.13.3

[tperfitt]

When attempting to compile on 10.13.3, I am getting errors on both CFStringEncodingConverter and wc16str. It looks like the CF framework was removed from macOS and is causing those errors. Additional errors include:

ld: library not found for -lCrashReporterClient
clang: error: linker command failed with exit code 1 (use -v to see invocation)

dcerpc-opensource/dcerpc/ncklib/gssauthcn.h:100:10: fatal error: 'GSS/gssapi_spi.h' file not found
#include <GSS/gssapi_spi.h>

gssapi_spi appears to be part of the Heimdal private framework.

Any suggestion on getting the framework to compile on macOS 10.13?

[jpeach]

Yeh on macOS we always had build dependencies on internal frameworks and SPI (IRC CFStringEncodingConverter was SPI). We can definitely make crash reported optional and probably make the GSS SPI headers optional, but we definitely need a string encoder

[tperfitt]

These look similar to what NSString/CFString provides: extern const CFStringEncodingConverter __CFConverterASCII; extern const CFStringEncodingConverter __CFConverterISOLatin1; extern const CFStringEncodingConverter __CFConverterMacRoman; extern const CFStringEncodingConverter __CFConverterWinLatin1; extern const CFStringEncodingConverter __CFConverterNextStepLatin; extern const CFStringEncodingConverter __CFConverterUTF8;

Would it involve more than putting a wrapper around those for the functionality? It would introduce platform dependencies but could be targeted just for the Mac.

[jpeach]

In ancient times we wanted to keep the Foundation runtime out of lower level services that consumed DCERPC but I think that basically everything has the objc runtime linked in now so thats probably not a concern. The other reason we used the SPI was that it removes some memory copies (you otherwise end up with extra CFString temporaries IIRC).

I'd be fine with taking a patch for whatever makes it work :)

[tperfitt]

Submitted pull request #12