Using the toolchain from Xcode 9b1 9M136h, including ld64-301.1, and the 10.13 SDK (probably not relevant), I see the following non-fatal warnings from the linker during a build:

[15937/29380] SOLINK libnet.dylib libnet.dylib.TOC
ld: warning: pointer not aligned at address 0x1049184 (__ZN12_GLOBAL__N_1L22GSS_C_NT_USER_NAME_VALE + 4 from obj/net/net/http_auth_gssapi_posix.o)
ld: warning: pointer not aligned at address 0x104919C (__ZN12_GLOBAL__N_1L29GSS_C_NT_MACHINE_UID_NAME_VALE + 4 from obj/net/net/http_auth_gssapi_posix.o)
ld: warning: pointer not aligned at address 0x10491B4 (__ZN12_GLOBAL__N_1L28GSS_C_NT_STRING_UID_NAME_VALE + 4 from obj/net/net/http_auth_gssapi_posix.o)
ld: warning: pointer not aligned at address 0x10491CC (__ZN12_GLOBAL__N_1L32GSS_C_NT_HOSTBASED_SERVICE_X_VALE + 4 from obj/net/net/http_auth_gssapi_posix.o)
ld: warning: pointer not aligned at address 0x10491E4 (__ZN12_GLOBAL__N_1L30GSS_C_NT_HOSTBASED_SERVICE_VALE + 4 from obj/net/net/http_auth_gssapi_posix.o)
ld: warning: pointer not aligned at address 0x10491FC (__ZN12_GLOBAL__N_1L22GSS_C_NT_ANONYMOUS_VALE + 4 from obj/net/net/http_auth_gssapi_posix.o)
ld: warning: pointer not aligned at address 0x1049214 (__ZN12_GLOBAL__N_1L24GSS_C_NT_EXPORT_NAME_VALE + 4 from obj/net/net/http_auth_gssapi_posix.o)
ld: warning: pointer not aligned at address 0x104922C (__ZN3net35CHROME_GSS_SPNEGO_MECH_OID_DESC_VALE + 4 from obj/net/net/http_auth_gssapi_posix.o)

These symbols all refer to structures come from https://chromium.googlesource.com/chromium/src/+/d479b3c2ca75e2508e2a2b3c661a9bfb746b4ef9/net/http/http_auth_gssapi_posix.cc, like

29  static gss_OID_desc GSS_C_NT_USER_NAME_VAL = {
30    10,
31    const_cast<char*>("\x2a\x86\x48\x86\xf7\x12\x01\x02\x01\x01")
32  };

gss_OID_desc from <GSS/gssapi.h> is

typedef struct gss_OID_desc_struct {
  OM_uint32 length;  // OM_uint32 is uint32_t
  void  *elements;
} gss_OID_desc, *gss_OID;

However, this structure and many others in the file are wrapped in #pragma pack(push, 2), which allows the elements member to sidle up against length without any padding in between, at offset 4. This is an unaligned pointer, which on x86_64 would normally need to be aligned to an 8-byte boundary, or offset 8 here.

Apple discusses this warning in their WWDC 2017 session 413, “App Startup Time: Past, Present, and Future” (https://developer.apple.com/videos/play/wwdc2017/413/). See the video starting at 22:49 for some introduction, and 23:31 for this precise warning, and the slides in the companion PDF starting at PDF page 133. The gist is that the loader will continue to deal with unaligned pointers for now, but in the future, for modules linked against newer SDKs, they’ll stop supporting this.

It appears that most of the OIDs that we define in this way are also available from the system (see <GSS/gssapi_oid.h>), under the same names that we use, except that CHROME_GSS_SPNEGO_MECH_OID_DESC is available as GSS_SPNEGO_MECHANISM. We could switch to using these.

I found in review history that there’s a reason to not use the system’s definitions for these (https://codereview.chromium.org/8038051#msg6), but I wonder if that’s still true, or at least if it’s still true for macOS. It would be nice to not have to duplicate stuff that the system gives us, and it would be nice to let this be Apple’s problem and not have to worry about it in our own build now that it’s throwing warnings.