Hi.

• Can you provide the error message / logs of the build failure you were seeing?
• Has a patch been submitted upstream?

@iMichka sure:

==> perl ./Configure --prefix=/usr/local/Cellar/openssl@1.1/1.1.1g --openssldir=/usr/local/etc/openssl@1.1 no-ssl3 no-ssl3-meth
==> make
Last 15 lines from /Users/andre/Library/Logs/Homebrew/openssl@1.1/02.make:
         ^
crypto/aes/aesni-mb-x86_64.s:533:10: error: unexpected token in argument list
 movq -16(%rax),%rbp

That's the error if you don't include no-asm.

I don't know what you mean by an upstream patch, because homebrew explicitly tells openssl to optimize for x86_64 in the other config flags. See the line above my patch, where the flag is darwin64-x86_64-cc. This is simply configuring Openssl to not include x86 assembly when we aren't on x86.

Oh. Rereading my original comment now, I now see why you asked about an upstream patch! Sorry about the misleading statement, this seems to purely be an issue with the way Homebrew is configuring OpenSSL and hardcoding x86.

This makes sense.

Out of interest, is the output binary still x86_64 compiled? It doesn't really matter just now because Rosetta but is worth noting.

@Bo98 looks like it's purely arm64 to me:

$ lipo -info /usr/local/Cellar/openssl@1.1/1.1.1g/lib/libssl.dylib
Non-fat file: /usr/local/Cellar/openssl@1.1/1.1.1g/lib/libssl.dylib is architecture: arm64

Cool - thanks for checking! I was wondering since darwin64-x86_64-cc passes -arch x86_64, but I think the Homebrew superenv does some magic to filter that out

Could you verify that the other parameters here openssl/openssl#12254 are also passed?

@SMillerDev I'm having trouble seeing what you mean. At least some of those parameters directly contradict existing Homebrew config. For example, the config you linked enables zlib, while the Homebrew formula already explicitly disables zlib. Which parameters do you think should be added, exactly, and why?

Since there is some Mojave runner setup issue and fixed by @Bo98, going to cancel the two ongoing builds. (will trigger a new run after clearing the queued PRs)

Run log, https://github.com/Homebrew/homebrew-core/actions/runs/152330222

Which parameters do you think should be added, exactly, and why?

I mostly just wanted to make you aware of the information there and if any other flags are needed based on that information you can add them as well. I don't know enough about homebrews openssl choices to pick specific ones for you.

@SMillerDev got it, thanks! I did see that ticket, and I figure there will likely eventually be an official platform for homebrew to use when building. Until then, I believe this is the only needed flag—I tested this patch on both x86 and arm macs and it produced working native openssl on each.

Can confirm that this works just fine on ARM.

I was able to brew install -s wget on ARM using this fix, and use it to download a TLS-served page without any errors.
I did a similar check with python@3.8 using urllib.request.urlopen.

@lionellloh @MikeMcQuaid something is off about the linter complaining about non-existing methods here.

Rerunning the CI now since it's been fixed.

@lionellloh @MikeMcQuaid something is off about the linter complaining about non-existing methods here.

Hi @SMillerDev, do you have more information how I may replicate this?

@lionellloh Not your fault and all addressed now. Was an issue with CI running master but your code not being in a tagged/stable release yet.

@MikeMcQuaid Is another CI run warranted here? Or shall we rather fast-track this PR?
I double-checked that the change works just fine. It also obviously has zero impact on the Intel universe.

Seeing how it's not a revision bump I'm fine with merging

Merged! No need to run again through CI for something that's going to 1) take ages and 2) not actually test the change.

Thanks for your contribution @indirect! 🍻

We are aware of that. This was accepted to help our maintainers to get things going for ARM native builds. What should have done? Stay stuck for 1 month? This was a stop-gap measure, for an unsupported configuration, so there is no real reason to complain about this.
There is a follow up PR here #65473.

Another thing: I do not really like the tone used here. Please be nice to people and maintainers, and read our code of conduct: https://github.com/Homebrew/.github/blob/HEAD/CODE_OF_CONDUCT.md#code-of-conduct

@mlindner Firstly: to imply we didn’t know what we’re doing seems pretty harsh, doesn’t it? We don’t appreciate such tone of voice, and I invite you to read and abide by our code of conduct.
Secondly, the upstream project just didn’t yet have any assembly for macOS/arm64 at the time this PR was merged.
Finally, it clearly says it’s a stop-gap, not a permanent solution.
Are we talking about the same thing?

(Edit: @iMichka beat me to it.)