deps: ntlmclient: provide platform-independent htonll implementation

[pks-t]

With the introduction of ntlmclient, we've started playing whac-a-mole
with platforms to support the non-standard htonll function. Let's end
this game once and for all by providing a generic implementation that's
implemented via htonl(3P) and a endianness-check in CMake.

[pks-t]

/cc @ethomson

[ryandesign]

Could this be done without requiring the endianness to be detected in the cmake script, but rather detecting it at build time in compat.h using preprocessor defines that are provided by the compiler? On some platforms like macOS it is possible to build for multiple architectures simultaneously (e.g. cc -arch i386 -arch x86_64 -arch ppc ...) in which case it is not possible to know at cmake time what the endianness or bitness will be at build time.

[ryandesign]

For example, __BIG_ENDIAN__ or __LITTLE_ENDIAN__ is defined by macOS compilers so this should work on macOS:

#ifdef __BIG_ENDIAN__
static inline uint64_t ntlm_htonll(uint64_t value)
{
	return value;
}
#else

# include <arpa/inet.h>

static inline uint64_t ntlm_htonll(uint64_t value)
{
	return ((uint64_t)htonl(value) << 32) + htonl((uint64_t)value >> 32);
}

#endif

I don't know what defines other systems use.

[ethomson]

On some platforms like macOS it is possible to build for multiple architectures simultaneously (e.g. cc -arch i386 -arch x86_64 -arch ppc ...) in which case it is not possible to know at cmake time what the endianness or bitness will be at build time.

This isn't something that we support out-of-the-box already. Our cmake recipes determine the bitness of the machine (see GIT_ARCH_64), so you couldn't -arch i386 -arch x86_64. Supporting this seems like a reasonable goal but I don't think that we should block this on that. We'd probably just want to do the quadfat magic ourselves with lipo 🤷‍♂️ .

[ethomson]

Although having said that, we do need to let people who build without CMake deal with this properly.

We have a pattern for the libgit2 defines (like GIT_ARCH_64) in features.h, but we don't have any pattern for the NTLM dependency. ☹️

[ryandesign]

so you couldn't -arch i386 -arch x86_64.

Building with -arch i386 -arch x86_64 does succeed, but it is certainly possible that what gets built that way doesn't work correctly.

Supporting this seems like a reasonable goal but I don't think that we should block this on that. We'd probably just want to do the quadfat magic ourselves with lipo

You probably don't want to add any code to do multi-architecture builds. It's fine to leave that up to the users who want to do it. For the sake of MacPorts, I'll switch our libgit2 build over to the build-multiple-times-and-lipo approach.

[ethomson]

Building with -arch i386 -arch x86_64 does succeed, but it is certainly possible that what gets built that way doesn't work correctly.

Interesting. I'll have to do a little investigation here. I suspect that - assuming that you're doing the build on amd64 (which I certainly hope is true 😁) that the i386 version may have some issues. I'll have to 👀

[ethomson]

We'll need to add this to config.h.in to support non-CMake users.

[ethomson]

Fixed with #5658 which won't require any changes to config.h.in or require non-CMake users to make any changes.