Opened 7 months ago

Last modified 7 months ago

#62293 new defect

clang-9.0 @ 9.0.1_3: Build failure on El Capitan with Xcode 7.3.1

Reported by: SerpentChris (Chris Calderon) Owned by:
Priority: Normal Milestone:
Component: ports Version: 2.6.4
Keywords: Cc: kencu (Ken), larryv (Lawrence Velázquez), jeremyhu (Jeremy Huddleston Sequoia)
Port: clang-9.0

Description

I asked about this on the mailing list and it was suggested that I make a ticket. This failure happened on two of my machines three times, all on fresh installs of El Capitan. I've attached the main.log from my third attempt.

Attachments (1)

main.log.tar.gz (289.6 KB) - added by SerpentChris (Chris Calderon) 7 months ago.
Compressed because the uncompressed file size was too large to upload.

Download all attachments as: .zip

Change History (3)

Changed 7 months ago by SerpentChris (Chris Calderon)

Attachment: main.log.tar.gz added

Compressed because the uncompressed file size was too large to upload.

comment:1 Changed 7 months ago by kencu (Ken)

Chris, before I do a deep dive here, could you take a moment and confirm for me that your Xcode matches your Command Line Tools, and that you have stock SDKs installed without any enhancements or symlinks added.

This is just good MacPorts maintenance, but can cause confusion if there are any discrepancies. Here is mine on BigSur, for example:

% xcrun -find clang
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang

% /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang -v
Apple clang version 12.0.0 (clang-1200.0.32.29)
Target: x86_64-apple-darwin20.3.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin

% /Library/Developer/CommandLineTools/usr/bin/clang -v
Apple clang version 12.0.0 (clang-1200.0.32.29)
Target: x86_64-apple-darwin20.3.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin

and

% xcrun --show-sdk-path
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk

% % ls -la  /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/
total 0
drwxr-xr-x  5 root  wheel  160 26 Jan 21:39 .
drwxr-xr-x  6 root  wheel  192 26 Jan 21:38 ..
drwxr-xr-x  5 root  wheel  160 26 Jan 21:38 DriverKit20.2.sdk
drwxr-xr-x  7 root  wheel  224 26 Jan 21:38 MacOSX.sdk
lrwxr-xr-x  1 root  wheel   10 15 Dec 22:58 MacOSX11.1.sdk -> MacOSX.sdk

% ls -la  /Library/Developer/CommandLineTools/SDKs    
total 0
drwxr-xr-x  6 root  wheel  192 27 Jan 14:07 .
drwxr-xr-x  5 root  wheel  160  2 May  2020 ..
lrwxr-xr-x  1 root  wheel   14 27 Jan 14:07 MacOSX.sdk -> MacOSX11.1.sdk
drwxr-xr-x  7 root  wheel  224 27 Jan 14:07 MacOSX11.1.sdk

comment:2 Changed 7 months ago by kencu (Ken)

The error in the log is:

/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_llvm-9.0/clang-9.0/work/llvm-9.0.1.src/tools/clang/tools/extra/clangd/Context.cpp:23:10: error: thread-local storage is not supported for the current target
:info:build   static thread_local auto C = Context::empty();
:info:build          ^
:info:build 1 error generated.
:info:build make[2]: *** [tools/clang/tools/extra/clangd/CMakeFiles/obj.clangDaemon.dir/Context.cpp.o] Error 1

To avoid this error on other systems, and yet make bootstrapping as easy as possible, the build of clang-9.0 currently does this:

    if {${subport} eq "clang-${llvm_version}" && ${os.major} <= 14} {
        configure.args-append -DCLANG_ENABLE_CLANGD=OFF
    }

It would appear that on darwin 15 systems with older Xcodes, they may not be able to build clangd either, and might need to have that blocker tweaked to:

    if {${subport} eq "clang-${llvm_version}" && ${os.major} <= 15} {
        configure.args-append -DCLANG_ENABLE_CLANGD=OFF
    }

This is not a big issue, as nobody on 10.11 will want to use clangd anyway, I submit (I suspect nobody on MacPorts has probably ever used clangd for anything, except on the very current systems).

You would say perhaps we should check the xcode version instead, and use the xcodeversion PortGroup -- but there has been an issue raised in other ports (cctools, for example) where testing the xcodeversion failed when a user did not have the full Xcode installed.

I am not at this moment 100% certain if we can or can not use an xcode version test in a PortFile if there are only the CLTs installed without Xcode being installed.

clang-8.0 and clang-9.0 already do use this -- holdovers from before the CLT-only plan -- and it seems to work for now, so I just left it.

Note: See TracTickets for help on using tickets.