Repository: spack/spack

Issue:
libsm: don't link to libuuid on macOS
We already do this in the `python` package. We should really be doing this for every package that depends on `libuuid`, but this is the specific package that broke my build. See https://github.com/spack/spack/pull/18322#issuecomment-743919707 for a better long-term solution.


Discussion:
#18322 is close to completion so this PR may not be needed for long. I would be fine with closing this. 

Resolving patch:
diff --git a/var/spack/repos/builtin/packages/apple-libuuid/package.py b/var/spack/repos/builtin/packages/apple-libuuid/package.py
new file mode 100644
--- /dev/null
+++ b/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'))
diff --git a/var/spack/repos/builtin/packages/python/package.py b/var/spack/repos/builtin/packages/python/package.py
--- a/var/spack/repos/builtin/packages/python/package.py
+++ b/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('uuid', when='+uuid')
     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')
 
     # Python needs to be patched to build extensions w/ mixed C/C++ code:
     # https://github.com/NixOS/nixpkgs/pull/19585/files


Test patch: