Use system libuuid on macOS (#20608)

etc/spack/defaults/darwin/packages.yaml

@@ -25,6 +25,8 @@ packages:
       - libelf
       unwind:
       - apple-libunwind
+      uuid:
+      - apple-libuuid
   apple-libunwind:
     buildable: false
     externals:
@@ -32,3 +34,10 @@ packages:
     # although the version number used here isn't critical
     - spec: apple-libunwind@35.3
       prefix: /usr
+  apple-libuuid:
+    buildable: false
+    externals:
+    # Apple bundles libuuid in libsystem_c version 1353.100.2,
+    # although the version number used here isn't critical
+    - spec: apple-libuuid@1353.100.2
+      prefix: /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr

var/spack/repos/builtin/packages/apple-libuuid/package.py

@@ -0,0 +1,45 @@
+# Copyright 2013-2020 Lawrence Livermore National Security, LLC and other
+# Spack Project Developers. See the top-level COPYRIGHT file for details.
+#
+# SPDX-License-Identifier: (Apache-2.0 OR MIT)
+
+from spack import *
+
+
+class AppleLibuuid(BundlePackage):
+    """Placeholder package for Apple's analogue to non-GNU libuuid"""
+
+    homepage = "https://opensource.apple.com/tarballs/Libsystem/"
+
+    version('1353.100.2')
+
+    provides('uuid')
+
+    # Only supported on 'platform=darwin'
+    conflicts('platform=linux')
+    conflicts('platform=cray')
+
+    @property
+    def libs(self):
+        """Export the Apple libuuid library.
+
+        According to https://bugs.freedesktop.org/show_bug.cgi?id=105366,
+        libuuid is provided as part of libsystem_c. The Apple libsystem_c
+        library cannot be linked to directly using an absolute path; doing so
+        will cause the linker to throw an error 'cannot link directly with
+        /usr/lib/system/libsystem_c.dylib' and the linker will suggest linking
+        with System.framework instead. Linking to this framework is equivalent
+        to linking with libSystem.dylib, which can be confirmed on a macOS
+        system by executing at a terminal the command `ls -l
+        /System/Library/Frameworks/System.Framework` -- the file "System" is a
+        symlink to `/usr/lib/libSystem.B.dylib`, and `/usr/lib/libSystem.dylib`
+        also symlinks to this file. Running `otool -L /usr/lib/libSystem.dylib`
+        confirms that it will link dynamically to
+        `/usr/lib/system/libsystem_c.dylib`."""
+
+        return LibraryList('/usr/lib/libSystem.dylib')
+
+    @property
+    def headers(self):
+        """Export the Apple libuuid header."""
+        return HeaderList(self.prefix.include.uuid.join('uuid.h'))

var/spack/repos/builtin/packages/python/package.py

@@ -7,7 +7,6 @@
 import os
 import platform
 import re
-import sys
 
 import llnl.util.tty as tty
 from llnl.util.lang import match_predicate
@@ -167,14 +166,8 @@ class Python(AutotoolsPackage):
     depends_on('libffi', when='+ctypes')
     depends_on('tk', when='+tkinter')
     depends_on('tcl', when='+tkinter')
-    depends_on('tix', when='+tix')
-    if sys.platform != 'darwin':
-        # On macOS systems, Spack's libuuid conflicts with the system-installed
-        # version and breaks anything linked against Cocoa/Carbon. Since the
-        # system-provided version is sufficient to build Python's UUID support,
-        # the easy solution is to only depend on Spack's libuuid when *not* on
-        # a Mac.
     depends_on('uuid', when='+uuid')
+    depends_on('tix', when='+tix')
 
     # Python needs to be patched to build extensions w/ mixed C/C++ code:
     # https://github.com/NixOS/nixpkgs/pull/19585/files