Compiling on macOS 12.0 Monterey fails

[SMillerDev]

I did this

After discovering that the Homebrew build (on 11.0) curl was very slow when running curl --version I tried reinstalling curl from source. This failed with the following error:

libtool: link: clang -dynamiclib -Wl,-undefined -Wl,dynamic_lookup -o .libs/libcurl.4.dylib  .libs/libcurl_la-altsvc.o .libs/libcurl_la-amigaos.o .libs/libcurl_la-asyn-ares.o .libs/libcurl_la-asyn-thread.o .libs/libcurl_la-base64.o .libs/libcurl_la-bufref.o .libs/libcurl_la-c-hyper.o .libs/libcurl_la-conncache.o .libs/libcurl_la-connect.o .libs/libcurl_la-content_encoding.o .libs/libcurl_la-cookie.o .libs/libcurl_la-curl_addrinfo.o .libs/libcurl_la-curl_ctype.o .libs/libcurl_la-curl_des.o .libs/libcurl_la-curl_endian.o .libs/libcurl_la-curl_fnmatch.o .libs/libcurl_la-curl_get_line.o .libs/libcurl_la-curl_gethostname.o .libs/libcurl_la-curl_gssapi.o .libs/libcurl_la-curl_memrchr.o .libs/libcurl_la-curl_multibyte.o .libs/libcurl_la-curl_ntlm_core.o .libs/libcurl_la-curl_ntlm_wb.o .libs/libcurl_la-curl_path.o .libs/libcurl_la-curl_range.o .libs/libcurl_la-curl_rtmp.o .libs/libcurl_la-curl_sasl.o .libs/libcurl_la-curl_sspi.o .libs/libcurl_la-curl_threads.o .libs/libcurl_la-dict.o .libs/libcurl_la-doh.o .libs/libcurl_la-dotdot.o .libs/libcurl_la-dynbuf.o .libs/libcurl_la-easy.o .libs/libcurl_la-easygetopt.o .libs/libcurl_la-easyoptions.o .libs/libcurl_la-escape.o .libs/libcurl_la-file.o .libs/libcurl_la-fileinfo.o .libs/libcurl_la-formdata.o .libs/libcurl_la-ftp.o .libs/libcurl_la-ftplistparser.o .libs/libcurl_la-getenv.o .libs/libcurl_la-getinfo.o .libs/libcurl_la-gopher.o .libs/libcurl_la-hash.o .libs/libcurl_la-hmac.o .libs/libcurl_la-hostasyn.o .libs/libcurl_la-hostcheck.o .libs/libcurl_la-hostip.o .libs/libcurl_la-hostip4.o .libs/libcurl_la-hostip6.o .libs/libcurl_la-hostsyn.o .libs/libcurl_la-hsts.o .libs/libcurl_la-http.o .libs/libcurl_la-http2.o .libs/libcurl_la-http_chunks.o .libs/libcurl_la-http_digest.o .libs/libcurl_la-http_negotiate.o .libs/libcurl_la-http_ntlm.o .libs/libcurl_la-http_proxy.o .libs/libcurl_la-http_aws_sigv4.o .libs/libcurl_la-idn_win32.o .libs/libcurl_la-if2ip.o .libs/libcurl_la-imap.o .libs/libcurl_la-inet_ntop.o .libs/libcurl_la-inet_pton.o .libs/libcurl_la-krb5.o .libs/libcurl_la-ldap.o .libs/libcurl_la-llist.o .libs/libcurl_la-md4.o .libs/libcurl_la-md5.o .libs/libcurl_la-memdebug.o .libs/libcurl_la-mime.o .libs/libcurl_la-mprintf.o .libs/libcurl_la-mqtt.o .libs/libcurl_la-multi.o .libs/libcurl_la-netrc.o .libs/libcurl_la-non-ascii.o .libs/libcurl_la-nonblock.o .libs/libcurl_la-openldap.o .libs/libcurl_la-parsedate.o .libs/libcurl_la-pingpong.o .libs/libcurl_la-pop3.o .libs/libcurl_la-progress.o .libs/libcurl_la-psl.o .libs/libcurl_la-rand.o .libs/libcurl_la-rename.o .libs/libcurl_la-rtsp.o .libs/libcurl_la-select.o .libs/libcurl_la-sendf.o .libs/libcurl_la-setopt.o .libs/libcurl_la-sha256.o .libs/libcurl_la-share.o .libs/libcurl_la-slist.o .libs/libcurl_la-smb.o .libs/libcurl_la-smtp.o .libs/libcurl_la-socketpair.o .libs/libcurl_la-socks.o .libs/libcurl_la-socks_gssapi.o .libs/libcurl_la-socks_sspi.o .libs/libcurl_la-speedcheck.o .libs/libcurl_la-splay.o .libs/libcurl_la-strcase.o .libs/libcurl_la-strdup.o .libs/libcurl_la-strerror.o .libs/libcurl_la-strtok.o .libs/libcurl_la-strtoofft.o .libs/libcurl_la-system_win32.o .libs/libcurl_la-telnet.o .libs/libcurl_la-tftp.o .libs/libcurl_la-timeval.o .libs/libcurl_la-transfer.o .libs/libcurl_la-url.o .libs/libcurl_la-urlapi.o .libs/libcurl_la-version.o .libs/libcurl_la-version_win32.o .libs/libcurl_la-warnless.o .libs/libcurl_la-wildcard.o .libs/libcurl_la-x509asn1.o vauth/.libs/libcurl_la-cleartext.o vauth/.libs/libcurl_la-cram.o vauth/.libs/libcurl_la-digest.o vauth/.libs/libcurl_la-digest_sspi.o vauth/.libs/libcurl_la-gsasl.o vauth/.libs/libcurl_la-krb5_gssapi.o vauth/.libs/libcurl_la-krb5_sspi.o vauth/.libs/libcurl_la-ntlm.o vauth/.libs/libcurl_la-ntlm_sspi.o vauth/.libs/libcurl_la-oauth2.o vauth/.libs/libcurl_la-spnego_gssapi.o vauth/.libs/libcurl_la-spnego_sspi.o vauth/.libs/libcurl_la-vauth.o vtls/.libs/libcurl_la-bearssl.o vtls/.libs/libcurl_la-gskit.o vtls/.libs/libcurl_la-gtls.o vtls/.libs/libcurl_la-keylog.o vtls/.libs/libcurl_la-mbedtls.o vtls/.libs/libcurl_la-mbedtls_threadlock.o vtls/.libs/libcurl_la-mesalink.o vtls/.libs/libcurl_la-nss.o vtls/.libs/libcurl_la-openssl.o vtls/.libs/libcurl_la-rustls.o vtls/.libs/libcurl_la-schannel.o vtls/.libs/libcurl_la-schannel_verify.o vtls/.libs/libcurl_la-sectransp.o vtls/.libs/libcurl_la-vtls.o vtls/.libs/libcurl_la-wolfssl.o vquic/.libs/libcurl_la-ngtcp2.o vquic/.libs/libcurl_la-quiche.o vquic/.libs/libcurl_la-vquic.o vssh/.libs/libcurl_la-libssh.o vssh/.libs/libcurl_la-libssh2.o vssh/.libs/libcurl_la-wolfssh.o   -framework CoreFoundation -framework SystemConfiguration -framework Security -L/usr/local/Cellar/openssl@1.1/1.1.1l/lib -L/usr/local/Cellar/libssh2/1.9.0_1/lib -L/usr/local/Cellar/rtmpdump/2.4+20151223_1/lib -L/usr/local/Cellar/libidn2/2.3.2/lib -L/usr/local/Cellar/nghttp2/1.44.0/lib -lnghttp2 -lidn2 -lrtmp -lssh2 -lssl -lcrypto -lgssapi_krb5 -lresolv -lldap -llber -lzstd -lbrotlidec -lz  -Os   -framework CoreFoundation -framework SystemConfiguration -framework Security -install_name  /usr/local/Cellar/curl/7.78.0/lib/libcurl.4.dylib -compatibility_version 12 -current_version 12.0 -Wl,-single_module -Wl,-exported_symbols_list,.libs/libcurl-symbols.expsym
ld: unaligned pointer(s) for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[1]: *** [libcurl.la] Error 1
make: *** [install-recursive] Error 1

I expected the following

A successful build, as it would on macOS 11.0.

curl/libcurl version

curl: stable 7.78.0

operating system

Darwin Gooseberry.local 21.1.0 Darwin Kernel Version 21.1.0: Thu Aug 19 02:54:46 PDT 2021; root:xnu-8019.40.29~26/RELEASE_X86_64 x86_64

[SMillerDev]

I know this is a macOS pre-release, so you can close this if you expect the final release to be unaffected.

[bagder]

For all we know that might just as well be a compiler/tool set problem right?

[SMillerDev]

Yeah, it could be anything. Although I am using the latest versions of all parts.

[bagder]

Still, without a better identification of what the problem is I don't know what we can do. The exact same code builds on a huge amount of platforms and compilers without that problem.

[albhaf]

Assuming it was built from source using brew reinstall curl -s, I was able to get seemingly the same error using the same configuration on b0eda8d when linking libcurl.4.dylib:

./configure --prefix=/usr/local/Cellar/curl/7.79.0 --with-ssl=/usr/local/opt/openssl@1.1 --without-ca-bundle --without-ca-path --with-ca-fallback --with-secure-transport --with-default-ssl-backend=openssl --with-libidn2 --with-librtmp --with-libssh2 --without-libpsl --with-gssapi

make
...
ld: warning: cannot export hidden symbol _curl_jmpenv from .libs/libcurl_la-hostip.o
ld: warning: pointer not aligned at address 0x80022 (_Curl_krb5_mech_oid + 4 from .libs/libcurl_la-curl_gssapi.o)
ld: unaligned pointer(s) for architecture x86_64

This was using ld64-710.1 from Xcode 13 beta 4. Running the same command with ld64-650.9 from Xcode 12 works fine (only emitting the hidden symbol warning). Same with using Xcode 12 for the entire build.

[CamJN]

ld64-711 also has this issue: ld: unaligned pointer(s) for architecture x86_64 That's on the latest beta of Monterey, and the latest CLT afaict.

[CamJN]

RfidResearchGroup/proxmark3#1485
RfidResearchGroup/proxmark3@2b3cd6e

Those links suggest that the packed attribute might be related (arm64 instead of amd64 but same toolchain).

[bagder]

Did they ship any updated tools? Does this problem remain?

If this is a toolset problem, shouldn't this problem also be visible in other projects? Anyone seen that?

[CamJN]

I saw it when compiling https://github.com/Snaipe/Criterion/

[SMillerDev]

Did they ship any updated tools? Does this problem remain?

They didn't ship updated tools yet, the problem remains

[nickzman]

FWIW, I just installed the Monterey RC + Xcode 13.1 RC on my M1 Mac, updated the command line tools, downloaded the latest curl source code, made a new configure script, and did this:

./configure --disable-shared --enable-debug --with-secure-transport --with-gssapi

And it built and ran correctly, with or without the --with-gssapi present.

[Bo98]

on my M1 Mac

The issue only affects x86_64.

[CamJN]

The change in 20e980f is odd, it changes the type of Curl_spnego_mech_oid.elements from char (*)[7] (essentially char**) to char*, which isn't just a constness change. Is that really ok?

[Bo98]

How it is now matches how Heimdal (the implementation Apple use) and krb5 implementations do it:

https://opensource.apple.com/source/Heimdal/Heimdal-597.140.2/lib/gssapi/mech/gss_oid.c.auto.html

https://github.com/krb5/krb5/blob/6fe25e755f510c0fc86b899d96db9f80acf03ac5/src/tests/gssapi/common.c#L37

https://github.com/krb5/krb5/blob/34625d594c339a077899fa01fc4b5c331a1647d0/src/lib/gssapi/generic/gssapi_generic.c#L38

[CamJN]

Thanks for the examples. I'm surprised it ever worked before then.

[bagder]

It worked just fine before too.

In the old code:

static char spnego_oid_bytes[] = "\x2b\x06\x01\x05\x05\x02";
gss_OID_desc Curl_spnego_mech_oid = { 6, &spnego_oid_bytes };

The &spnego_oid_bytes would end up a pointer to the static string, exactly like it is now.

The difference now being that the xcode tools don't go nuts on this version.