openssl3: error: too many arguments to function call, expected 1, have 2

[catap (Kirill A. Korinsky)]

A naive attempt to build it from scratch is failed as:

crypto/threads_pthread.c:192:45: error: too many arguments to function call, expected 1, have 2
    if (__atomic_is_lock_free(sizeof(*val), val)) {
        ~~~~~~~~~~~~~~~~~~~~~               ^~~
crypto/threads_pthread.c:193:16: warning: implicit declaration of function '__atomic_add_fetch' is invalid in C99 [-Wimplicit-function-declaration]
        *ret = __atomic_add_fetch(val, amount, __ATOMIC_ACQ_REL);
               ^
crypto/threads_pthread.c:219:45: error: too many arguments to function call, expected 1, have 2
    if (__atomic_is_lock_free(sizeof(*val), val)) {
        ~~~~~~~~~~~~~~~~~~~~~               ^~~
crypto/threads_pthread.c:220:16: warning: implicit declaration of function '__atomic_or_fetch' is invalid in C99 [-Wimplicit-function-declaration]
        *ret = __atomic_or_fetch(val, op, __ATOMIC_ACQ_REL);
               ^
crypto/threads_pthread.c:244:45: error: too many arguments to function call, expected 1, have 2
    if (__atomic_is_lock_free(sizeof(*val), val)) {
        ~~~~~~~~~~~~~~~~~~~~~               ^~~
crypto/threads_pthread.c:245:33: error: too many arguments to function call, expected 2, have 3
        __atomic_load(val, ret, __ATOMIC_ACQUIRE);
        ~~~~~~~~~~~~~           ^
<built-in>:13:26: note: expanded from macro '__ATOMIC_ACQUIRE'
#define __ATOMIC_ACQUIRE 2
                         ^
2 warnings and 4 errors generated.

[ryandesign (Ryan Carsten Schmidt)]

Please attach the main.log file.

[catap (Kirill A. Korinsky)]

Reported to upstream: ​https://github.com/openssl/openssl/issues/18055

[catap (Kirill A. Korinsky)]

Proposed a fix to upstream: ​https://github.com/openssl/openssl/pull/18056

[neverpanic (Clemens Lang)]

If you don't mind, I'd appreciate a PR with a backport of the patch for the openssl3 Portfile. I don't have such an old system on which I could test.

[catap (Kirill A. Korinsky)]

Replying to neverpanic:

If you don't mind, I'd appreciate a PR with a backport of the patch for the openssl3 Portfile. I don't have such an old system on which I could test.

I'll do it, as soon as upstream review it. This is trivial but need to be tested still.

Feel free to reasign this ticket to me and I'll take care of it.

[kencu (Ken)]

openssl3 already installs as is on my 10.7 system with no modifications:

$ uname -a
Darwin macbook21.local 11.4.2 Darwin Kernel Version 11.4.2: Thu Aug 23 16:26:45 PDT 2012; root:xnu-1699.32.7~1/RELEASE_I386 

$ port -v installed openssl3
The following ports are currently installed:
  openssl3 @3.0.2_0+legacy (active) requested_variants='' platform='darwin 11' archs='x86_64' date='2022-03-26T08:22:11-0700'

[kencu (Ken)]

I believe @catap's Xcode is not the correct version.

$ sh -c 'printf "%s\n" "macOS `sw_vers -productVersion` `sw_vers -buildVersion` `uname -m`" "`xcodebuild -version|awk '\''NR==1{x=$0}END{print x" "$NF}'\''`"'|tee /dev/tty|pbcopy
macOS 10.7.5 11G63 i386
Xcode 4.6.3 4H1503

$ clang -dM -E -x c /dev/null | grep apple
#define __apple_build_version__ 4250028

[catap (Kirill A. Korinsky)]

Ken, let move to OpenSSL's issue to keep everything in one place. Why? Because I can reproduce it without MacPorts.

[kencu (Ken)]

We have two different issues, perhaps.

1. openssl3 builds fine on MacPorts for me and for the buildbot, using the system compiler, but (I believe) not for you for reasons to be discovered. Possibly relating to the clang version.
2. openssl may not build on a raw 10.7 system outside MacPorts. I'm not really in that horserace at the moment.

[catap (Kirill A. Korinsky)]

Ken, I suggest to wait upstream decision for my PR.

[kencu (Ken)]

Whatever upstream openssl might think about 10.7, have you any idea though why your openssl3 build is uniquely failing on MacPorts?

Something is not right on your system, and that always makes me nervous for someone doing a lot of PRs…

[catap (Kirill A. Korinsky)]

Ken, I've try to build it for bootstrap macports to obtain curl. To make things simple and faster I've also switched bootstrap mackports to cxx_stdlib libstdc++; maybe it was trigger that uncover an issue.

Thus, I have quite a karma for discovering wired and rare issues :) not only in software, in life also.

[kencu (Ken)]

yes, if you have switched to cxx_stdlib libstdc++ that might well cause the atomic failure, indeed.

There is a significant difference in atomic handling between the system libstdc++, libc++, libc++ with c++11 enabled, and (for clangs that support it) macports-libstdc++.

Those are all quite different animals and I did not try as yet the bootstrap version of curl with the cxx_stdlib set to libstdc++, or any of those other variations, so that could indeed show an issue.

As you dig hard on these things, especially on these older systems, you do indeed turn up all the idiosyncrasies in the various builds!

[catap (Kirill A. Korinsky)]

After a lot of digging and with Ken help I can confirm that update of command line tools fixes an issue.

Can some one close it?