Apple Silicon M系列芯片 macOS 配置CMake/Makefile生成x86_64架构二进制/库文件

ikun-fans

于 2025-02-21 12:02:35 发布

阅读量117

点赞数 2

文章标签： macos

本文链接：https://blog.youkuaiyun.com/u012456479/article/details/145773823

版权

Makefile环境变量

export CFLAGS="-arch x86_64"
export CPPFLAGS="-arch x86_64"

CMake配置FLAGS

string(APPEND CMAKE_CXX_FLAGS " -arch x86_64")
string(APPEND CMAKE_CC_FLAGS " -arch x86_64")

ikun-fans

博客等级

码龄12年

50
原创

187
点赞

326
收藏

123
粉丝

关注

私信

分类专栏

skia 1篇
Rust 1篇
zynq 1篇

最新评论

关于std::memory_order_consume
ikun-fans: 这篇文章是想讨论一个非常不常用的、晦涩的选项：memory_order_consume 也建议不要用这个，直接配合使用memory_order_acquire即可。consume需要特别小心。因此，最佳的实践就是Guard.load使用memory_order_acquire，也因此，当然不能使用memory_order_relaxed了~
关于std::memory_order_consume
ikun-fans: 1. 你还是没理解memory_order描述的，建议仔细看看https://zh.cppreference.com/w/cpp/atomic/memory_order 2.且不说原理，你说的逻辑就有问题哦： 1).首先memory_order_release并不是强制排序。假定你认为它能强制排序，想想是不是就不需要其他的order了？ 2).你也说需要配合使用。acquire和release正是最普遍的一种配合使用方式。不然release和relaxed配合也能达到效果岂不是设计多余了？？相当于r一个elease走天下了，其实最严格的order也做不到，就是需要配合使用才行的。可以重点看看这个：宽松定序被标以 memory_order_relaxed 的原子操作不是同步操作；它们不会为并发的内存访问行为添加定序约束。它们只保证原子性和修改顺序的一致性。释放-获取定序若线程 A 中的一个原子存储被标以 memory_order_release，而线程 B 中从同一变量的原子加载被标以 memory_order_acquire，且线程 B 中的加载读到了线程 A 中的存储所写入的值，则线程 A 中的存储同步于线程 B 中的加载。从线程 A 的视角先发生于原子存储的所有内存写入（包括非原子及宽松原子的），在线程 B 中成为可见副效应。即一旦原子加载完成，则保证线程 B 能观察到线程 A 写入内存的所有内容。仅当 B 实际上返回了 A 所存储的值或其释放序列中后面的值时，才有此保证。同步仅建立在释放和获得同一原子变量的线程之间。其他线程可能看到与被同步线程的一者或两者相异的内存访问顺序。
关于std::memory_order_consume
Shisw_X: 注意第二条：在其他线程，使用consume能保证该原子变量的带依赖写入（文中的g）可见。换言之relaxed不能保证这一点。也就是： Payload = 42; Guard.store(&Payload, memory_order_release); 1 2 在另一个线程看起来可能是： Guard.store(&Payload, memory_order_release); Payload = 42; ———————————————— 这里不正确吧，既然已经使用了memory_order_release，其他线程不可能看到Playload=42在Guard.store之后，不然memory_order_release的强制排序岂不是不起作用。文章最后说的memory_order要搭配使用这没错，但没说一定要搭配使用，memory_order_release的强制排序才会起作用啊。
Skia最新版CMake编译
mayohn: 大佬，depot tools用的是哪个版本
Lambda和闭包(closure) 及其在C++中的实现原理
_熵: 一篇文章解决许多问题，很不错嘛