在macOS上面运行Linux 上的软件

下面现学现卖

如果单说现代的类nix系统中是否“向下”兼容UNIX标准，可以说基本都兼容。但是要说所有现代类nix系统之间兼容程度如何，就要问哪个（Linux）发行版本与哪个 (Unix)版本的哪些部分兼容，毕竟每个Linux发行版本之间也有兼容问题。本人还真的说不好，没有特别的深入所以没有实际体会。大家叫做它们*nix的，都一定程度 可以彼此兼容，同时都有各自不同程度的扩展。

刚才看了看SUS的标准部分，它的测试程序不免费需购买，所以没法像Linux系统那样随手拈来地使用。而且它的注册保有这个这个许可也是老贵了（Note 0).

从Unix角度说，原教旨的Unix几乎绝迹了，参考下Wikipedia上的Unix的解释（Note 2），特别是那个关系图最直观。举一个例子，UNIX的Base Specifications, Issue 7, 2018 Edition中的12.2 Utility Syntax Guidelines的前面三条说明来说（Note 3）：

Guideline 1: Utility names should be between two and nine characters, inclusive.

Guideline 2: Utility names should include lowercase letters (the lower character classification) and digits only from the portable character set.

Guideline 3: Each option name should be a single alphanumeric character (the alnum character classification) from the portable character set. The -W (capital-W) option shall be reserved for vendor options. Multi-digit options should not be allowed.

随着各个操作系统的扩展，它们很多都不符合这些规则（也没必要完全符合）。可以举出很多的Linux/OS X系统中的命令的例子不符合这三个规则，就如apt-get命令的"-"就不符合规则2，再如OS X中的networksetup命令也不符合第一条；更别说现在流行使用的“--”参数格式了。

同样是grep命令，Linux中的-T选项在Solaris和Mac中没有，在Mac上也没有-u参数（Note 4），那-T和-u两个参数都是各自版本的扩展，在标准中没有这两个参数，更没有--version这类的。如果一个程序使用-T参数，那么它在Solaris和Mac 上的运行结果就可能不正确，但是各个版本都支持--version/--color/--null的参数，那么一个程序虽然不符合UNIX标准，但是却可以在多个系统中使 用。

现代操作系统，仅仅满足UNIX标准是没有生命力的，对于非开源的软件来说和各自基于的硬件平台的不同，必定造成各自的发展会相去很多。UNIX标准在现代操作系统中的作 用是较局限的。UNIX标准对于现今的系统来说，它涵盖的内容很有限，拿UNIX 03标准来说，它主要是包括4个方面（Note 1）：

The UNIX 03 Product Standard is built out of the following subsidiary Product Standards:

• Internationalized System Calls and Libraries Extended V3
• Commands and Utilities V4
• C Language V2
• Internationalized Terminal Interfaces

尤其是当涉及到操作系统特性的编程时，可移植性就会有很多的疑问。从原来的Unix的纯文本界面，到现在的内核+GUI的系统，有了很大的改进。具体到某一个软件本身，就 要具体问题具体分析了。

要说为什么现在好多Linux软件都可以比较容易的跨平台安装使用，个人认为，主要是它们都使用了现成通用的轮子/齿轮和底盘（服务/程序/库/语言等），只要这些轮子全 被成功移植到一个平台就可以了。

这些文章说的可能更清楚些：Linux vs Unix和Linux Vs Unix: The Crucial Differences That Matter To Linux Professionals

Note 0: The Open Brand Fee Schedule

Note 1: 2.1.2 The UNIX 03 Product Standard

Note 2: Unix

Note 3: https://publications.opengroup.org/c181

Note 4：https://blogs.warwick.ac.uk/peggleton/entry/grep_on_solaris；https://linux.die.net/man/1/grep；https://developer.apple.com/legacy/library/documentation/Darwin/Reference/ManPag es/man1/grep.1.html

我就说点自己的理解和搜索的小结：

macOS是POSIX-compliant, Open Brand UNIX 03 Registered Product（Apple官方文档说辞http://movies.apple.com/media/us/osx/2012/docs//OSX_for_UNIX_Users_TB_July2011.p df）

UNIX 03是单一UNIX规范（Single UNIX Specification, 简称SUS）规范的一个版本。符合该规范的系统，如果申请/声明符合某某版本（SUS version 2/3/4等）的规范，在得到兼容认证后，就可以在自己的产品中标识它是符合UNIX 03的产品。为什么是SUS不是UNIX呢，因为有版权控制权等等之争（参考https://en.wikipedia.org/wiki/Unix_wars）...

在实际系统中，可以一方面符合该规范，还有会各自的扩展；有的系统可能不符合，但是安装附加系统后，也可以符合；有的是符合的，但是没去做认证和注册，也就无法“名正言顺 ”地声明，几乎所有Linux似乎就是这个现状，毕竟申请/认证/注册是要银子的。查看注册的可以到这里：https://www.opengroup.org/openbrand/register/index2.html

一个程序是否可以移植在不同的操作系统中，一方面看它源代码是否符合各个操作系统所遵循规范的交集，一方面看它所调用/依赖的库是否符合目标操作系统规范，即便没有随系统 安装至少也得是可以通过额外安装而获得支持。

源代码兼容/编译码兼容/机器码兼容：

软件之所以在同一种操作系统的不同版本中可以运行，是编译码兼容。如果编译码不兼容，但是源代码兼容，那么可以通过在目标系统上对源代码编译后，就可以得到一个兼容该系统 的编译码程序。如果源代码都不兼容，可以修改源代码中不兼容的代码，获得一个该系统的特定版本的源代码，这部分工作就是软件移植中的工作。

编译器就是将源代码编译为本地系统规范的机器代码。比如x86-64和RISC、PowerPC连机器码都不兼容，那肯定要重新编译。而之所以AMD和Intel两个平台 可以互换，是他们机器码兼容；之所以基于相同硬件平台（如Intel）的不同操作系统下的软件不能通用，主要是各个系统的规范不同，而机器代码是相同的。gcc和clan g等都是编译器，只要是它们支持的编程语言都可以进行代码编译，个人认为主要差别是代码优化部分。

无论是apt或deb还是brew，他们都是通过网上对软件的源代码、移植操作和依赖等的汇总关系表，再根据本地系统的特性，实现下载/依赖补全/移植改动/编译/安装/ 配置等一全套自动化操作，而实现软件移植安装的。那么apt/deb/brew是否能在03系统之间移植呢？可能可以。它们各自依赖的那些关系表都是针对各自操作系统的， 关系表之间主要不同是“移植”部分，就是针对不同操作系统对源代码进行修正的操作，对于需要做“移植”操作的软件，比如对硬盘设备操作，linux上用sda*，而mac OS上是disk*s*的形式（仅仅是举例），操作的转化和逻辑会有很大不同，不移植会出问题。

管见，也是手生脑子也锈住了。

我很理解你的需要。关于在 Mac 上运行程序，这里有一个小的误区。问题中进行了一长串的逻辑推断，但是方向反了。我们来仔细看一下：macOS 基于 UNIX，Linux也基于UNIX，所以应该说，macOS 和 Linux 都可以运行大部分 UNIX 程序。但是因为两者都是「基于」UNIX，也就是说，各自对 UNIX 有不同的延伸和扩展，所以 macOS 和 Linux 之间，为其中一个系统开发的程序不一定可以用在另一个系统。

一个简单的例子是，iOS 和 Mac 都基于 UNIX，但是程序也不一定通用。Apple 也从来没有说过两者的程序可以简单地交换使用。

另外，deb 包管理器只是 Debian/Ubuntu 系列 Linux 发行版的默认选择，在 RHEL 系列，对应的是 rpm。这也可以看出，即使是不同 Linux 系列之间也有差别，即使一些东西可以转化。

幸运的是，很多在 Linux 下日常用到的程序其实都不只有 Linux 版本，而也有 Mac 甚至 Windows 版本。在 Mac 上，人们常常用 HomeBrew（brew）下载、编译、安装那些常见于 Linux，而需要在 Mac 上用到的程序。

我想我可能没有表述清楚。我想要描述的是，两者有一些差别，并不是直接将 Linux 的软件拷贝到 Mac 上就能运行（我也了解到你十分明白这一点），但是也不是说源代码拿到 Mac 下就可以编译。

从 5 年前开始，Mac 官方支持的编译器就不再是 gcc 了，而是 Apple 的 Clang，这一编译器随 Xcode 提供，或者直接从 Apple 开发者网站下载。在 Mac 终端下直接使用 gcc 命令时，其实也是调用的 Clang，相当于 gcc 在 Mac 上只是 Clang 的别名。但是不是说不能用 gcc，你也可以在相关网站下载用于 Mac 的 gcc。

在 Mac 上用 gcc 并不容易，举一个例子：在 Linux 上，“> gcc -lOpenCL” 就可以使用 OpenCL 的库；但是 Mac 上，虽然 gcc 是 Clang 的别名，但是这个 -l 的用法并不支持，而是需要 “> clang -framework OpenCL”。

不知道你现在想要做的是什么，需要达到什么预期效果？

维基百科是一个自由的百科网站，但并不是权威的信息来源，任何人都可以注册一个账号编辑上面的内容。这也导致维基百科记载的内容不一定是最新的，也不一定是正确、可信的。 关于那些开发工具的兼容性和使用问题，可以到更加专业的社区提问，或者搜索更多的帖子，阅读更可靠的介绍。

我需要指出，我没有否定 gcc 能够用在 Mac 上的事实。

这张截图里面的信息很多，不过并没有提到 gcc 用在现时的 macOS 上，是否能够利用到 macOS 所有的最新技术。如果是为 Mac she ji应用程序，在众多的选择里，可以选择 gcc，不过在 Mac 下的使用可能没有 Clang 那么方便（毕竟 Clang 有官方的支持）。当然，gcc 也可以用于在 Mac 上编译用于其他平台的程序，具体配置根据实际使用需求而定。

所以还是那个问题，你的预期效果是什么？

gcc 的确应该可以用那些框架，但是需要多一些的配置，可能没有直接用 Xcode 来得快。要更好地解决你的疑问，如果可以描述具体的使用场景也许会更快一些？

Android Studio 里面很多部分是运行的 Java。

Objective-C 只是一门编程语言，没有限制编译运行只能在 Mac 上，只要系统和库支持就可以。