clang-15 builds for multiple archs even without the universal variant which fails

[ryandesign (Ryan Carsten Schmidt)]

clang-15 builds for multiple archs (i386 and x86_64 and even x86_64h!) even without the universal variant being selected which fails on OS X 10.11 when it tries to link with the legacy support library which has been built only for x86_64.

​https://build.macports.org/builders/ports-10.11_x86_64-builder/builds/195291/steps/install-port/logs/stdio

cd /opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_lang_llvm-15/clang-15/work/build/projects/compiler-rt/lib/sanitizer_common && /opt/local/bin/clang++-mp-14 -DHAVE_RPC_XDR_H=0 -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -I/opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_lang_llvm-15/clang-15/work/build/projects/compiler-rt/lib/sanitizer_common -I/opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_lang_llvm-15/clang-15/work/llvm-project-15.0.1.src/compiler-rt/lib/sanitizer_common -I/opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_lang_llvm-15/clang-15/work/build/include -I/opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_lang_llvm-15/clang-15/work/llvm-project-15.0.1.src/llvm/include -I/opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_lang_llvm-15/clang-15/work/llvm-project-15.0.1.src/compiler-rt/lib/sanitizer_common/.. -pipe -Os -DNDEBUG -D__DISABLE_MP_LEGACY_SUPPORT_SYSCONF_WRAP__=1 -D__DISABLE_MP_LEGACY_SUPPORT_REALPATH_WRAP__=1 -isystem/opt/local/include/LegacySupport -I/opt/local/include  -fPIC -fvisibility-inlines-hidden -Werror=date-time -Werror=unguarded-availability-new -Wall -Wextra -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wmissing-field-initializers -pedantic -Wno-long-long -Wc++98-compat-extra-semi -Wimplicit-fallthrough -Wcovered-switch-default -Wno-noexcept-type -Wnon-virtual-dtor -Wdelete-non-virtual-dtor -Wsuggest-override -Wstring-conversion -Wmisleading-indentation -Wall -std=c++14 -Wno-unused-parameter -O3 -DNDEBUG -arch i386 -arch x86_64 -arch x86_64h -stdlib=libc++ -mmacosx-version-min=10.10 -isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk -fPIC -fno-builtin -fno-exceptions -funwind-tables -fno-stack-protector -fno-sanitize=safe-stack -fvisibility=hidden -fno-lto -Wthread-safety -Wthread-safety-reference -Wthread-safety-beta -O3 -g -Wno-gnu -Wno-variadic-macros -Wno-c99-extensions -nostdinc++ -Wno-format -fno-rtti -Wframe-larger-than=570 -Wglobal-constructors -std=c++14 -MD -MT projects/compiler-rt/lib/sanitizer_common/CMakeFiles/RTSanitizerCommonNoTermination.osx.dir/sanitizer_deadlock_detector1.cpp.o -MF CMakeFiles/RTSanitizerCommonNoTermination.osx.dir/sanitizer_deadlock_detector1.cpp.o.d -o CMakeFiles/RTSanitizerCommonNoTermination.osx.dir/sanitizer_deadlock_detector1.cpp.o -c /opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_lang_llvm-15/clang-15/work/llvm-project-15.0.1.src/compiler-rt/lib/sanitizer_common/sanitizer_deadlock_detector1.cpp
ld: warning: ignoring file /opt/local/lib/libMacportsLegacySupport.a, file was built for archive which is not the architecture being linked (i386): /opt/local/lib/libMacportsLegacySupport.a
Undefined symbols for architecture i386:
  "__dyld_get_shared_cache_range", referenced from:
      __sanitizer::get_dyld_hdr() in sanitizer_procmaps_mac.cpp.o
ld: symbol(s) not found for architecture i386
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[2]: *** [lib/clang/15.0.1/lib/darwin/libclang_rt.stats_osx_dynamic.dylib] Error 1

[cjones051073 (Chris Jones)]

Compilers are a bit different to regular ports, in that its normal for a single platform build of a compiler to support targeting multiple architectures. So the above is actually expected, its normal for the compiler to support targeting i386, within a x86_64 build of the compiler, to support cross compilation.

The question then is how to reconcile this with the use of legacy-support..

Note though, its not clear if the message above is a red-herring for legacy-support, as it anyway doesn't provide __dyld_get_shared_cache_range. The warning is just saying its ignored the static lib, not that it would actually have helped.

[cjones051073 (Chris Jones)]

b.t.w. we have had issues with i386 support in the llvm-devel builds. Which is why we have

​https://github.com/macports/macports-ports/blob/e3d8b60d1feaa6cc3794460ee139a74243900d9b/lang/llvm-devel/Portfile#L131

It might be something similar is needed with llvm-15..

[ryandesign (Ryan Carsten Schmidt)]

Replying to cjones051073:

Compilers are a bit different to regular ports, in that its normal for a single platform build of a compiler to support targeting multiple architectures. So the above is actually expected, its normal for the compiler to support targeting i386, within a x86_64 build of the compiler, to support cross compilation.

Certainly...

Note though, its not clear if the message above is a red-herring for legacy-support, as it anyway doesn't provide __dyld_get_shared_cache_range. The warning is just saying its ignored the static lib, not that it would actually have helped.

Ah, you are probably right that I have mistakenly attributed the problem to legacysupport.

Replying to cjones051073:

b.t.w. we have had issues with i386 support in the llvm-devel builds. Which is why we have

​https://github.com/macports/macports-ports/blob/e3d8b60d1feaa6cc3794460ee139a74243900d9b/lang/llvm-devel/Portfile#L131

It might be something similar is needed with llvm-15..

I don't think that's relevant exactly, since changing supported_archs would just prevent MacPorts from requesting that the port be built for i386, but as I said, in this case, the build system has decided to build for i386 all on its own without MacPorts' involvement.

There is a note at the bottom of the llvm-12 Portfile that may be relevant however?

# Note 1:

# lldb-12 build fails on 10.11 with this link error at 98% of the build:
#Undefined symbols for architecture x86_64:
#  "__dyld_get_shared_cache_range", referenced from:
#      lldb_private::HostInfoMacOSX::GetSharedCacheImageInfo(llvm::StringRef) in liblldbHostMacOSXObjCXX.a(HostInfoMacOSX.mm.o)
#  "__dyld_get_shared_cache_uuid", referenced from:
#      lldb_private::HostInfoMacOSX::GetSharedCacheImageInfo(llvm::StringRef) in liblldbHostMacOSXObjCXX.a(HostInfoMacOSX.mm.o)
#  "_dyld_shared_cache_iterate_text", referenced from:
#      lldb_private::HostInfoMacOSX::GetSharedCacheImageInfo(llvm::StringRef) in liblldbHostMacOSXObjCXX.a(HostInfoMacOSX.mm.o)

# This appears related to this commit in the lldb build tree, which would appear to be non-trivial to work around:
# https://github.com/llvm/llvm-project/commit/8113a8bb793453832301e2684dc2b8cebec331b0
# building against a newer SDK may or may not be an option for someone motivated to have lldb-12 on < 10.12

[cjones051073 (Chris Jones)]

Yeah, historically build failures in the lldb-X ports have been much less of a problem, as these are rarely used, so often we just let them pass. If something like that though is affecting the LLVM build thats much more of an issue.

[cjones051073 (Chris Jones)]

Note, the above relates to sanirtizers, which themselves are not critical to the operation of the compilers and in fact we already disable them in the RT support.

​https://github.com/macports/macports-ports/blob/e3d8b60d1feaa6cc3794460ee139a74243900d9b/lang/llvm-15/Portfile#L336

I'll need to do some investigation to see if there is some other option to turn them off 'even more'...

[cjones051073 (Chris Jones)]

Actually... Now I look again we only turn them off on macOS 10.10 and older. So lets just see if extending that to 10.11 helps.

[Chris Jones <jonesc@…>]

In b826f1252ff58dd326f0a859cbf4aa1573df7251/macports-ports (master):

{c,f}lang-15: Extend disabling sanitizers to 10.11 and older
See: #65887

[cjones051073 (Chris Jones)]

Appears to have done the trick…