clang-14 @14.0.6_0+analyzer+libstdcxx+universal: no matching function for call to 'min'

[thetrial (alabay)]

After a very, very long building time, it ends with an error – and again, my build-chain is broken. After mlir-14 now clang-14. Due to it says that clang-14 builds under El Capitan, maybe it’s an issue of a variant. Universal?

:info:build /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_llvm-14/clang-14/work/llvm-project-14.0.6.src/lld/MachO/SyntheticSections.cpp:1193:21: error: no matching function for call to 'min'
:info:build                     std::min(codeEnd - code, static_cast<ssize_t>(blockSize)));
:info:build                     ^~~~~~~~
:info:build /opt/local/libexec/llvm-11/bin/../include/c++/v1/algorithm:2560:1: note: candidate template ignored: deduced conflicting types for parameter '_Tp' ('int' vs. 'long')
:info:build min(const _Tp& __a, const _Tp& __b)
:info:build ^
:info:build /opt/local/libexec/llvm-11/bin/../include/c++/v1/algorithm:2571:1: note: candidate template ignored: could not match 'initializer_list<type-parameter-0-0>' against 'int'
:info:build min(initializer_list<_Tp> __t, _Compare __comp)
:info:build ^
:info:build /opt/local/libexec/llvm-11/bin/../include/c++/v1/algorithm:2580:1: note: candidate function template not viable: requires single argument '__t', but 2 arguments were provided
:info:build min(initializer_list<_Tp> __t)
:info:build ^
:info:build /opt/local/libexec/llvm-11/bin/../include/c++/v1/algorithm:2551:1: note: candidate function template not viable: requires 3 arguments, but 2 were provided
:info:build min(const _Tp& __a, const _Tp& __b, _Compare __comp)
:info:build ^
:info:build 1 error generated.

Log is attached.

[jmroot (Joshua Root)]

Yes, it's the i386 build that's broken.

[thetrial (alabay)]

I’d say I wouldn’t need i386, but I guess it’s up to the dependances. And all the wine stuff is i386 it seems. Though I’m on 64er machines.

[jmroot (Joshua Root)]

In 2fda12633ba31941b1d1f44210b525de2c135d9e/macports-ports (master):

clang-14: attempt to fix i386 build

See: #65423

[jmroot (Joshua Root)]

Replying to thetrial:

I’d say I wouldn’t need i386, but I guess it’s up to the dependances. And all the wine stuff is i386 it seems. Though I’m on 64er machines.

Using +universal when you don't need it is certainly going to make your life more difficult. Try without it and see what happens I guess?

[thetrial (alabay)]

I tried that several times before. Then the universal version gets loaded, when needed. That’s the problem. I did not call for clang-14, that’s automatically done due to need (by some port(s)). I’ll try again.

[thetrial (alabay)]

Hm … this time it worked. I simply installed clang-14, it turned out +analyzer +libstdcxx, and openal-soft did not kick off +universal. Interesting. Now is the question … why was +universal called before?

[ryandesign (Ryan Carsten Schmidt)]

When a port (like wine) needs its library dependencies built universal, MacPorts builds all of the dependencies universal, even build dependencies (like clang) which may not need to be universal.

[jmroot (Joshua Root)]

If you explicitly ask for +universal on the command line, that will be passed on to all dependencies, some of which you may not intend. But +universal is only added automatically in response to arch checking finding that a dependency has incompatible archs, and that is prevented by depends_skip_archcheck, which is used for all compilers that support the -arch flag: ​https://github.com/macports/macports-base/blob/master/src/port1.0/portconfigure.tcl#L1670

[thetrial (alabay)]

The problems are wine – depending on clang-14 and winetricks – depending on clang-13. For normal use I don’t hold up any clang. Maybe I should? But if, thet would be non-universal, and these would require universal, I guess. And building those universal types – if they go through – takes very, very long time.

[jmroot (Joshua Root)]

Well, in any case, the universal build of clang-14 succeeded now.

[thetrial (alabay)]

Well, segues into Ticket #65454.