Opened 2 years ago

Closed 2 years ago

Last modified 2 years ago

#65887 closed defect (fixed)

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

Reported by: ryandesign (Ryan Carsten Schmidt) Owned by:
Priority: Normal Milestone:
Component: ports Version: 2.7.2
Keywords: elcapitan Cc: cjones051073 (Chris Jones)
Port: llvm-15

Description

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

Change History (8)

comment:1 Changed 2 years ago by 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.

comment:2 Changed 2 years ago by 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..

comment:3 in reply to:  2 Changed 2 years ago by 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

comment:4 Changed 2 years ago by 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.

comment:5 Changed 2 years ago by 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'...

Version 0, edited 2 years ago by cjones051073 (Chris Jones) (next)

comment:6 Changed 2 years ago by 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.

comment:7 Changed 2 years ago by Chris Jones <jonesc@…>

In b826f1252ff58dd326f0a859cbf4aa1573df7251/macports-ports (master):

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

comment:8 Changed 2 years ago by cjones051073 (Chris Jones)

Resolution: fixed
Status: newclosed

Appears to have done the trick…

Last edited 2 years ago by cjones051073 (Chris Jones) (previous) (diff)
Note: See TracTickets for help on using tickets.