Build Issue on Macos/ARM: "TLS support is required."

[Vzor-]

On MacOS Ventura-arm, I could not configure the project. With LibreSSL 3.3.6 I got

configure: error: TLS support is required.
configure: error: ./configure failed for libcups

I was eventually able to get it to build by installing OpenSSL via brew and providing

PKG_CONFIG_PATH="/opt/homebrew/opt/openssl@3/lib/pkgconfig" \
./configure

This then led to make issues, but that should probably be its own issue.

[michaelrsweet]

I'll need the config.log file from the failed configure.

That said, libcups v3 does NOT support the native (but deprecated) macOS Security.framework TLS APIs. The same will be happening for CUPS 2.5 in the nearish future so it is important to have the config.log file and/or make output to help you build. I regularly build against LibreSSL on my systems - you'll need to make sure your local Libre/OpenSSL builds are "universal" (ARM + x86), otherwise the default configure + make will fail due to missing architecture bits (libcups builds universal by default on macOS).

[Vzor-]

configure.log Gist

[Vzor-]

I had a colleague check with his M1 mac and he had the same issue. I ran lipo -info /usr/bin/openssl and got Architectures in the fat file: /usr/bin/openssl are: x86_64 arm64e

and that is LibreSSL 3.3.6

For openSSL, I think it is thin, and that is the cause of the make issues. I think openssl is ALWAYS going to be thin when installed via brew.

[michaelrsweet]

OK, "arm64e" is the wrong architecture for Apple Silicon - it should just be "arm64".

[tresf]

I ran lipo -info /usr/bin/openssl

The build is targeting the brew version (/opt/homebrew/<etc>), but it's correct that brew doesn't build dual-arch by default.

you'll need to make sure your local Libre/OpenSSL builds are "universal" (ARM + x86), otherwise the default configure + make will fail due to missing architecture bits (libcups builds universal by default on macOS).

Is this the only blocker? If so, can we help add an option to stop this?

[tresf]

OK, "arm64e" is the wrong architecture for Apple Silicon - it should just be "arm64".

Are you sure? https://stackoverflow.com/a/65918986/3196753

I don't know the history of it, but it seems that some A13 instructions were added to the M1 processor, making this possible. That said, we were deliberately linking against the openssl version from Homebrew (mainly because I didn't know if Apple provided the necessary build files with the libressl version)

 % lipo -info $(brew --prefix openssl)/bin/openssl
Non-fat file: /opt/homebrew/opt/openssl@3/bin/openssl is architecture: arm64

[michaelrsweet]

Re: disabling universal binaries, right now the only option is the '--enable-debug' option to build non-release binaries. Otherwise you want code signing and universal binaries on macOS, and this is unique enough that I don't want to mess with configure options that only work on macOS. About all I would be willing to do is have the configure script not add -arch options if they are already present in the compiler/linker options ("OPTIM" environment variable).

Re: arm64e, I am 100% sure. When the first developer transition systems came out you could use arm64e because of the processor it used, but that changed in the first released products/OS to just "arm64". You'll get random exceptions on M1/M2 CPUs with "arm64e".

[michaelrsweet]

Re: the build log, it looks like the configure script can't find the LibreSSL-supplied pkgconfig files...

[tresf]

you want [...] universal binaries on macOS

Perhaps you do? I certainly don't, ever.

you want code signing [...] on macOS

This has nothing to do with code signing. Ideally, binaries are notarized if they're to be distributed, otherwise, I don't see an argument to make it harder for developers to build this tool.

You'll get random exceptions on M1/M2 CPUs with "arm64e".

Well, this is Ventura 13.4, so it's Apple's own, but we're not using it (and I'm not sure we can, we'd need a pkg-config (.pc) as well as headers, which I'm not even sure how to provide to the environment. @Vzor-'s PKG_CONFIG_PATH works for the brew version, but the linking issues he mentions occur.

right now the only option is the '--enable-debug' option to build non-release binaries.

We thought of this... This issue originally stemmed from a failed ippsample and passing --enable-debug didn't seem to initially fix this, but we may have run into some caching issues. We're happy to PR any documentation or make fixes, but even hard-coding -arch arm64 into the configure script didn't seem to fix this.

About all I would be willing to do is have the configure script not add -arch options if they are already present in the compiler/linker options ("OPTIM" environment variable).

This would be a welcome workaround, if it works. Of course, the ippsample would then need its submodule bumped, but it would offer a way to use the tool without recompiling openssl.

[tresf]

Re: the build log, it looks like the configure script can't find the LibreSSL-supplied pkgconfig files...

Should we be building against libressl instead of openssl or will both work?

[tresf]

We thought of this... This issue originally stemmed from a failed ippsample and passing --enable-debug didn't seem to initially fix this, but we may have run into some caching issues. We're happy to PR any documentation or make fixes, but even hard-coding -arch arm64 into the configure script didn't seem to fix this.

Hmm... retesting, this statement seems to be wrong:

./configure --enable-debug && make
# gets much further now

[tresf]

Ok, I updated the submodules and it's building using --enable-debug.

What's odd is I don't even need the openssl files from homebrew. @Vzor- there might be something specific to your environment preventing it from compiling with that flag.

That said, I think an option to disable fat binaries without enabling debug would be a good idea.

[tresf]

What's odd is I don't even need the openssl files from homebrew.

Oh, it's using gnutls, which through Homebrew doesn't provide x86_64 bindings.

brew install gnutls

[tresf]

@Vzor- the following also seems to succeed, but using openssl instead of gnutls:

PKG_CONFIG_PATH="/opt/homebrew/opt/openssl@3/lib/pkgconfig" \
./configure --enable-debug

... or more generically:

export PKG_CONFIG_PATH="$(brew --prefix openssl)/lib/pkgconfig"
./configure --enable-debug  

[michaelrsweet]

@tresf

Should we be building against libressl instead of openssl or will both work?

Both will work, we just look for the pkg-config files for "openssl" (which both OpenSSL and LibreSSL supply).

I added changes to the configure script that doesn't add options if they are already present:

[master ae9b9d0af] Don't build universal for macOS 10.14 or later if the developer already is using OPTIM.

So do one of the following to build release binaries for a single architecture:

OPTIM="-arch arm64" ./configure ...

OPTIM="-arch x86_64" ./configure ...

[tresf]

@michaelrsweet that works, thanks. @Vzor- this is safe to close.

# TLS support is required
 brew install gnutls

The next issue is when trying to run (e.g. ippserver) the following error occurs:

tresf@macbook-arm server % ./ippserver 
dyld[39435]: Library not loaded: /usr/local/lib/libcups3.3.dylib
  Referenced from: <810F496F-1983-368E-BC78-A2C83015EA4F> /Users/tresf/ippsample/server/ippserver
  Reason: tried: '/usr/local/lib/libcups3.3.dylib' (no such file), '/System/Volumes/Preboot/Cryptexes/OS/usr/local/lib/libcups3.3.dylib' (no such file), '/usr/local/lib/libcups3.3.dylib' (no such file), '/usr/lib/libcups3.3.dylib' (no such file, not in dyld cache)

I understand that ippsample is a separate project (and this is just trying to run after make). Would you rather we track this issue there as a separate bug report?

I assume this message is is due to a default install path of /usr/local/ as a throwback to x86_64 versions of homebrew? They've moved to /opt/homebrew/ for arm64 to easily differentiate the two (homebrew does not support multiarch/fat binaries).

[michaelrsweet]

@tresf You need to install the software, set the DYLD_LIBRARY_PATH environment variable (to point to the libcups/cups directory), or use the --disable-shared configure option so that the CUPS v3 shared library isn't used.

[Vzor-]

@tresf You need to install the software, set the DYLD_LIBRARY_PATH environment variable (to point to the libcups/cups directory), or use the --disable-shared configure option so that the CUPS v3 shared library isn't used.

This worked for me. Thanks a lot for the help.