@wk333 感谢回复，我更新了我的查找结果，请看 6 楼

@codehz
命令 file /usr/lib/rpm/redhat/redhat-annobin-cc1 结果是：
/usr/lib/rpm/redhat/redhat-annobin-cc1: symbolic link to redhat-annobin-select-annobin-built-plugin

命令 ll /usr/lib/rpm/redhat/redhat-annobin-cc1 结果是：
lrwxrwxrwx. 1 root root 42 Oct 4 23:54 /usr/lib/rpm/redhat/redhat-annobin-cc1 -> redhat-annobin-select-annobin-built-plugin

命令 file /usr/lib/rpm/redhat/redhat-annobin-select-annobin-built-plugin 结果是：
/usr/lib/rpm/redhat/redhat-annobin-select-annobin-built-plugin: ASCII text

命令 cat /usr/lib/rpm/redhat/redhat-annobin-select-annobin-built-plugin 结果是：
*cc1_options:
+ %{!-fno-use-annobin:%{!iplugindir*:%:find-plugindir()} -fplugin=annobin}

关于这个文件我找到了这个软件包的构建 git：
https://src.fedoraproject.org/rpms/redhat-rpm-config/tree/rawhide

这里面有和上面 cat 出来的信息完全相同的内容，请过目

ldd 查看的依赖都应该是运行依赖，直接手动执行构建的话，我查看了 lfs 手册，systemd 的运行依赖不可能包含 gcc 的动态库，也就是一楼手动构建完成后 ldd 看到链接的动态库对应是 glibc/libcap/zstd/xz ，而不应该对 gcc 有运行依赖。

我尝试将 spec 文件中的解压缩还有 meson 和 ninja 构建命令都拿到了一个子脚本中，通过在 spec 文件中执行 shell 脚本来构建，结果出来的 libsystemd 动态库依旧有 libgcc_s 的运行依赖


libgcc_s 库绝对路径中的路径/lib64 其实是/usr/lib64 的软链接，我怀疑 rpmbuild 在运行时临时产生了一些环境变量导致，我通过往子脚本中添加 set 和 env 命令抓出来了变量，然后和手动执行命令重定向的变量进行 diff ，发现有很多不同的地方，搜索关键字 lib64 还是能出来不少，明天再一个个对比下看看。。。好诡异。。。

@codehz 但 LDFLAGS 应该是链接库用的，这里面选项我查了下好像都不是和使用 libgcc 有什么关联的样子？我是否理解有什么错吗？

@codehz 你意思是手动构建的时候，meson 和 ninja 构建是直接连到了系统中的 libgcc.a ，而 rpm 构建的时候链接到了 libgcc_s.so ？

我能看到和 libgcc_s 有关的库：
find /usr/lib -name libgcc*结果有：
/usr/lib/gcc/aarch64-redhat-linux/13/libgcc.a

find /usr/lib64 -name libgcc*结果有：
/usr/lib64/libgcc_s-13-20230728.so.1
/usr/lib64/libgcc_s.so.1
/usr/lib64/libgccpp.so.1
/usr/lib64/libgccpp.so.1.5.0

ll /usr/lib64/libgcc_s.so.1 结果有：
lrwxrwxrwx. 1 root root 25 Jul 28 08:00 /usr/lib64/libgcc_s.so.1 -> libgcc_s-13-20230728.so.1

现在的问题是，systemd 是 meson 构建，我不知道如何传递 gcc 的选项参数给它。

rpmbuild 启动后会指定这些环境变量，这里面有没有可能导致走的链接 libgcc_s.so ？我知道 libgcc 有关的库是构建 gcc 源码的时候生成的库（之前测试过），但
+ CFLAGS='-O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -mbranch-protection=standard -fasynchronous-unwind-tables -fstack-clash-protection -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer '
+ export CFLAGS
+ CXXFLAGS='-O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -mbranch-protection=standard -fasynchronous-unwind-tables -fstack-clash-protection -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer '
+ export CXXFLAGS
+ FFLAGS='-O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -mbranch-protection=standard -fasynchronous-unwind-tables -fstack-clash-protection -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -I/usr/lib64/gfortran/modules '
+ export FFLAGS
+ FCFLAGS='-O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -mbranch-protection=standard -fasynchronous-unwind-tables -fstack-clash-protection -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -I/usr/lib64/gfortran/modules '
+ export FCFLAGS
+ VALAFLAGS=-g
+ export VALAFLAGS
+ LDFLAGS='-Wl,-z,relro -Wl,--as-needed -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -Wl,--build-id=sha1 -specs=/usr/lib/rpm/redhat/redhat-package-notes '
+ export LDFLAGS
+ LT_SYS_LIBRARY_PATH=/usr/lib64:
+ export LT_SYS_LIBRARY_PATH
+ CC=gcc
+ export CC
+ CXX=g++
+ export CXX

@air00dd 损坏的话刀锋钛看样子不是的，就是 cpu 电压低了导致网卡无法启动，之前还真没遇到过这毛病，好奇怪。。。而且 win10 相比 win11 调整好电源策略后，cpu 频率比 win11 低 0.1-0.2ghz 不知道什么情况，但看温度又是一样的。。。

@diguoemo 是的，看名字可能是 2 代，据说 3 代才算解决问题，不过我纳闷的是，为啥降压会导致这网卡无法启动，我改回自动电压再开机，网络可用了

@optional 我这英特尔 i7-13700k ，我尝试把电压改回来就恢复，降压居然会在 win 下网卡无法启动。。。而且 win10 下调整电源策略后，相比 win11 频率明显低 0.1-0.22ghz 不知道什么原因

@dxgfalcongbit 怎么说呢？请教下？加压超频坏了就真坏了，降压应该只能算不稳定吧？

@deorth 我把电压改回自动，然后重启进 ubuntu 安装盘，发现网络正常，再重启进 win 也正常了，看样子微星这板子降压超频会导致网卡启动不起来。。。

m1pro,16mbp 我还以为是我个例呢，还想着要不要换一个指纹识别，有时候指纹接触秒开，有时候需要按下去才有用，有时候怎么按都无效，而且没有办法稳定复现

bt/pt 协议下，想下载快，得有做种人，而且不仅要做种人多，他们多数人上传速度也要快，你才能下载得快，这是核心设计理念。

迅雷快是因为他下载有两种途径，目的都是从公网获取了其他人的共享资源，将这些资源归为己有，只分享给开会员的人，而且为所有装了迅雷软件的电脑强制已下载的资源进行做种，占用他们上传带宽。

这样，他们可用的上传来源就有两种人，一种是所有装了迅雷软件的电脑，一种是公网 bt tracker 能连上的人。

然后迅雷用户的下载渠道就有两种：
1. 公网 bt ，你不给钱也能下载，就是下载速度非常慢，这种情况就是迅雷连上公共 bt ，然后通过这些公共 bt tracker 连接到有在上传的人时的传输速度，这种速度理论上和传统 bt 软件下载资源时的速度一样快。
2. 迅雷私有会员渠道，如果不付费直接 0 速度，那就是这资源只在安装了迅雷软件且下载过该资源的迅雷用户电脑上有（无论是否有付费），因为迅雷强制这些用户电脑做种，所以但凡有资源被迅雷完整下载过，且那用户没有关掉迅雷进程且资源没被删除的话，其他迅雷用户只要开了会员就能下

所以吸血雷的名号由此而来，网上有很多科普介绍，其实都不靠谱，因为原理对不上

1. 学 linux 直接用你台式机装个 vmware 开虚拟机是最好的，别装实体机，出了问题你还得换电脑或手机查资料太过麻烦。除非你实在是太年轻还在上大学这种有大量空闲时间。

2. 如果非要装实体机，尽量买旧不买新，像 13 代 cpu 有不少 linux 发行版装不上或者装上开不了机

3. 尽量买核显机，mac 个人感觉更像是个工作的工具而不是学习平台。

4. 避免掉入美化的坑，绝大部分 linux 新手都会打着学习的名号把大量时间浪费在桌面美化上面。

5. 不要浪费时间在选择系统上面，有桌面环境希望软件新一些就 ubuntu 原版，否则 centos 原版，没桌面环境就 centos minimal 或 debian minimal ，系统就这四个选择就够了，新手目的学 linux 就别浪费时间在 arch 或 gentoo 之类的系统上

@BlueMacondo vmware workstation 开桥接虚拟机？装个 debian 之类的系统，然后 idea 这类软件可以远程开发？不过如果公司用 vpn 的话，你还有翻墙需求比如 clash 就翻不出去了，这俩只能有一个开着，来回切换多少会有些麻烦，所以考虑了下我还是上了 mbp16 ，本地性能够用，虽然回公司肯定会体验更好

@emiyamuto 有出差需求的话就 win 台式+mbp ，我个人是怎么搭配的

@KKKg 如果你以后会考虑 g604 的话，可以直接网上下载我的配置，早就提交到罗技的社区了，这些按键都是工作时经常用的，我买了两个 604 ，一颗 5 号电池能用 4 个月，按照我的使用习惯，已经完美实现了终身质保且不会因为寄回换货导致的中断使用影响工作的情况。

https://imgur.com/a/mZ1b1Kg
我鼠标的快捷键组合


你手腕位置是不是压桌上的?

你对不合并多行任务栏功能是否有刚需?如果有，千万别升级，我从 win11beta 首版就用到现在，现在已经转回 win10 了，amd5000 系 cpu 跟个老牛拉大车一样感觉，反应太慢了