C/C++的交叉编译，需要的无非是工具链（编译器、链接器、头文件和库）。

Clang 内置交叉编译，意思是 Clang 自己的源码支持平台 A-Z ，所以只要 Clang 本身被构建的时候勾上了对某平台（比如 aarch64 ）支持就没问题，但通常为了缩小体积，各种包管理里的 Clang 只会带 Host 架构支持，比如你是 x86 的机器，上面的 Clang 可能就只能编译到 x86 。所以用 Clang 的话需要搞一个支持你想要的目标平台的版本。GCC 定得更死一点，一个 GCC 只能支持一类目标平台，所以你得装一个特定的交叉编译 GCC （一般可执行文件名会带前缀），比如 gcc-mingw-w64 。

头文件和库，Linux 和 BSD 这类开源系统一般很容易搞到全套，Windows 注意下分 mingw 和 msvc 两套，macOS 也能下到。链接器麻烦一些，从 Linux 交叉编译基本只能用 GNU ld 或者 lld ，Windows 和 macOS 的 link.exe 和 ld64 没有其他平台的版本。总之你可以去参考 zig cc 包里的依赖，甚至直接用它就可以，从它交叉编译出 macOS 和 Windows 的 hello world 就是一分钟的事。

CMake 的配置可以参考下官方文档，核心也基本就是一些编译选项： https://cmake.org/cmake/help/book/mastering-cmake/chapter/Cross%20Compiling%20With%20CMake.html

我就是做编译器的，现在还在找工作中，可能比前面的 V 友相对更有发言权一点…这个领域上限当然是高，国内中科院有专门的实验室，看到认识的学弟飞去国外参加各种顶会。但不代表就业门槛真的就那么高，因为任何行当都有搬砖的不是？

就业角度，编译器好的地方在于，它能和很多领域沾边，所以就算传统编译器已经成熟了，也总能有几个关联方向火。比如前端方面，一是静态分析工具，二是国内外大厂到一定规模都会搞自己的语言（有的并不对外公开），三是搞 AI 加速芯片需要开发自己类似 CUDA 的 DSL ，这几个都对编译器前端技能有要求。

中端方面，很多 AI 的 workload 需要高层次的算子优化（也就是传说中的 AI 编译器），有些代码库非常大的公司也有针对性调优的需求，另外传统编译器里也有做中端优化的空间。

后端方面，面向经典 CPU 的传统编译器是最多的场景，每个指令集的 vendor 都会养一帮人维护后端（比如 intel 、arm ，像华为高通也有给开源编译器 arm 后端贡献代码），然后是各种 GPU 或者 NPU 后端，现在还有需求就是基于 RISCV 的各种魔改芯片也需要后端开发的人力。还有就是高级语言虚拟机，比如 JS 、Python 引擎这类，这种岗位国内很少，JVM 多一些。

差不多 2017 年以前，国内做编译器的团队很少，能找到的工作都是外企。后面贸易战，国内大笔投资芯片，RISCV 逐渐成熟，又有 AI 这波热度，Golang 、Rust 这些新语言流行也让大厂的基础设施团队发现了新 KPI 来源，总之现在编译器相关的岗其实比原来多了很多。18 年校招的时候面试腾讯，面试官说你想做什么我们腾讯什么都有，我说编译器，他尴尬地说这个真没有😅结果现在腾讯也有编译器岗了。

小不小众，肯定是不如 Web 或者云就业范围广的，但反过来也意味着不卷，总之各种 HR 都抱怨编译的人不好招。菊花的话，可能是家大业大，内部有非常多个团队（可能我能想到的就有 3-4 个）都在做编译器，所以有人才缺口。认识的行业内 35 岁以上的…也不少了，但大环境在这里，年龄总归对再就业有影响。等下个月把工作搞定打算再开个帖子讲讲。

@default7 永艺的一把什么椅子，算是普普通通吧

个人网站为什么要纠结 React 还是 Vue ？如果你的网站一没有复杂的交互，二只有一个人开发，三需要快速简洁，用这几个框架（也包括 ng ）就是本末倒置，杀鸡用牛刀。如果你是一个专业前端，对某个框架非常熟悉，出于习惯用它写个人网站没啥问题，但 OP 不是这种情况。

以前的人用 jQuery 是因为浏览器普遍兼容性特别差，jQuery 能够抹平很多浏览器兼容性问题。现在 2024 年了，主流浏览器（ Safari 、Firefox 、Chrome 、Edge ）可以放心使用现代 API 。个人网站以内容为主，不需要多少 JS ，你说的 Vue 、React 这些东西本身也没法帮你解决动画这些问题，反倒几行 CSS 就能搞定。

如果你不想写 CSS ，也有 Tailwind 这种东西，让 GPT 生成一组用 Tailwind 的 HTML ，自己改改就能上线，用前端框架说不定还在折腾工具链。

https://ecnelises.com/
我的这个应该算……简洁吧？

除开 Ruby 这类解释型动态语言不谈，Objective-C 显然更符合 Smalltalk 的理念。可惜的是除开其奇怪的语法，大多数人可能也没有多喜欢这种程度的动态性。

我不清楚 CFNetwork 和你项目的具体细节，但你可以用 Swift 对应的上层库 URLSession 看有没有这个问题。印象里，在 Objective-C 时代 iOS 发网络请求有很多的坑。

另外建议你还是先统一用 curl ，我有个要用到加密库的项目，本来也想在不同平台用各自的系统库，但这样做至少在初期弊大于利，需要多实现很多代码，行为也不一致，万一有什么安全问题开源库升级也比系统库方便，用系统库仅存的好处可能就是目标二进制体积更小一些，但 curl 本身也不大。

Unix 有一个通用的工具叫 chroot ，顾名思义就是在某个环境中把某个目录映射为 root ，理论上可以实现虚拟环境的功能。但 macOS 上这么折腾的毕竟少，要实现你的目的可能坑多。

我记得非常清楚，几年前在本站看到过一个 NVIDIA 员工发的帖子（一时找不到了），说他大约是在 11 年还是 13 年入职的，到现在财务自由就是靠公司股票。那时候还没有 ChatGPT 、没有生成式 AI. 如果在十年前那个阶段买入 NVIDIA 股票，到 20 年美国大放水之前差不多也有十倍收益，和今天这个涨幅自然不能比，但放在正常股票来看也了不得。

人是不能回到过去的，这种事即使放到梦里也显得有些奢侈，因为现今人类构筑的绝大多数体系，都建立在「时间是单向流动的」这个假设上。也就是说，如果自己真能回到过去，那今天 NVIDIA 的股票也不会值这么多钱。

如果你过去有本金但未做出你今天看来正确的决定，应该想的不是「如果我当时能 xxx 就好了」（虽然是人之常情），而是为什么自己当时没做出这个选择，一定有它的原因，一定是在当时看来这么做不会有这么大收益。这个才重要得多。人总是乐于美化过去而丑化未来。

@nnegier
可以用命令打出系统/Applications 目录下的应用程序的可执行文件依赖的动态库，比如 Firefox 就是 otool -L /Applications/Firefox.app/Contents/MacOS/firefox ，你会发现大部分软件都依赖了一大堆动态库，都是同样的系统路径

@draymonder
动态库在内存中的地址是不确定的，加载的时候才会分配地址空间，甚至对每个符号来说，它们的地址要到第一次被调用时才确定（延迟绑定），只是操作系统有虚拟内存机制，所以不同进程地址空间里的动态库地址实际上指向的是同一份。

@jimmy3780
好想法。不过我刚开始对它那个 Passkey 支持很摸不着头脑，以为是可以用 Passkey 解锁，没想到是保存 Passkey 登录其他网站，鉴于支持 Passkey 的网站基本都支持传统密码登录，感觉有点意义不明😂

粗略地讲，一个「程序」主要由两个部分构成：供 CPU 执行的代码区域和供代码读写的数据区域。对应地，每个.c .cpp 文件编译后的.o (Windows 上是.obj) 文件也有自己的代码区域和数据区域，最后由 ld (Windows 上是 link.exe) 把所有的代码区域合并为一个，数据区域也合并为一个，然后调整好里面引用的位置偏差。

大多数情况下，每个程序的数据区域都可以由这个程序任意读写，但代码区域是只读的。程序运行的时候，代码区域和数据区域都会被加载到内存中。顺着这个思路，假如系统里有很多个程序链接了一样的库，那每个链接了这个库的程序只需要复制一份库的数据区域以读写就行了，代码区域反正是只读的，内存里只用存一份，大家执行代码时都指向这个区域就行。因此，使用动态库可以减少内存占用，就是指这种情况下节省了多余的代码区域。

另外，很多程序会直接链接系统某个路径的动态库，运行的时候不同程序直接读取系统路径的就可以，而用静态库的话，每个程序都会把这个库被引用到的所有内容都打包进可执行文件里。所以动态库也可以减少磁盘空间占用。

@0o0O0o0O0o
大概就是每个系统自己的加解密 API ，比如 macOS/iOS 的 CryptoKit/CommonCrypto ，Windows 的 bcrypt. 好处是程序体积更小，配置简单，不过反正 Linux 平台上用的都是 OpenSSL/LibreSSL ，其他平台打包上一个这个也不是什么大问题。

打算写一个，现在想到的点：

- 兼容主流平台，最好用原生 UI （老版本系统可以战略性放弃）和原生加密 API
- 有浏览器插件（联动原生软件还是独立运行？）
- 有命令行程序提供一些底层命令供自动化
- 数据结构灵活，字段可定制
- 开源，有完备测试，加密流程部分参考几大密码管理器的技术白皮书
- 支持同步（ iCloud ？文件？如果可以也可以兼容 Bitwarden 协议？或者自建 API ）
- 能从其他密码管理器导出的数据导入，以及反过来导出到它们能接受的格式

1. LLVM 在构建的时候可以选择启用哪些 target ，macOS 的 AppleClang 可能只 enable 了 AArch64 和 X86 ，你自己 build 的 Clang 如果不传 LLVM_TARGETS_TO_BUILD 这个 CMake 选项那就是全部启用，也包括 WebAssembly

2. 苹果的 AppleClang 应该是对 include 和 library path 有一些魔改，你试着编译一个没有#include 的 C 文件然后-v 看就能发现。

AppleClang 是这样（以 Xcode Beta 为例）：
/usr/local/include
/Applications/Xcode-beta.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/15.0.0/include
/Applications/Xcode-beta.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include
/Applications/Xcode-beta.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include
/Applications/Xcode-beta.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/System/Library/Frameworks (framework directory)

社区源码编译的 Clang 是这样：
/usr/local/include
~/Developer/llvm/build/lib/clang/17/include
/System/Library/Frameworks (framework directory)
/Library/Frameworks (framework directory)

最简单的解决方法自然是把 Xcode 里那堆目录软链接到/usr/local/include 里。

继续尝试编译，发现提示-lSystem 找不到，跟着上面 Xcode Clang 的输出，加上-Wl,-syslibroot /Applications/Xcode-beta.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk 就可以。

嫌麻烦也可以把这个额外选项写到 Clang 的 config file 里：

https://clang.llvm.org/docs/UsersManual.html#configuration-files

@cosette
其实按 Option 点全屏按钮也不一定就是最大化，比如 Finder 和 Safari 就不行，是有个 API 可以让开发者返回软件当前认为最合适的尺寸，如果没有实现这个 API 就是最大化