gcc 10 尝鲜及后续
在 zimg 项目的 Issue 中看到这样一个问题,使用 gcc 10 编译出现了编译器把size_t
错认成std::size_t
,从而导致编译出错。看到这个问题有点惊讶,gcc居然都出到 10 了,支持了 C++20 的一些新特性,便想尝试一下。
看了 gcc 官网,10 版本还没发布编译好的版本,想了一下,比起自己编译,还是装个新版的 Fedora 系统更省事一点。
收集各种 Linux 发行版
说起来我也是用过复数个 Linux 发行版的人了,不再像一年前那样懵懂,能够比较从容地折腾这些发行版了。
Fedora 也是用 yum 管理依赖包,这才让我想起“我眼中的各 Linux 发行部用户”那张图。
fedora:红帽子家养的小白鼠无误,有什么新想(nao)法(dong)都先往 fedora 上招呼
Archlinux:战斗机,很厉害,B格很高
ubuntu:吉祥物,用自己的种种行为卖傻卖萌,负责 Linux 桌面推广,人民群众喜闻乐见,实际上没有卵用
redhat:我是负责服务器的工程师
CentOS:我是楼上那个工程师的影分身
gentoo linux:相比 Arch 这个战斗机,我已然冲出大气层
openSUSE:YAST 就是你的专职妹抖,用♂过都说好
Slackware:祖宗之法大于天(任何用户都应该自己解决包依赖)
debian:看过动画《轻音少女》的都知道,姐姐没有妹妹来照料起居,基本就活不下去……
Mint:ヨーロッパ是欧洲的意思,这表示 Mint 是 Ubuntu 偷渡欧洲了?
以上转自 Kan Kikou@知乎
Fedora
我对 Fedora 的感觉
- 用和 ArchLinux 一样的 GNOME 桌面
- 用和 CentOS/RedHat 一样的 yum 包管理
- 工具都是最新的
不过这倒是挺符合我的胃口,毕竟我就是从 CentOS 转到 ArchLinux 的。
回到 Fedora 本身,一开始用 workstation 版本,感觉对新手异常友好。但 Fedora 31 还没问题,Fedora 32 一进入安装界面就出现诡异的花屏。然而 Fedora 31 也没有 gcc 10 啊,遂转用 network install 版本。
倒是挺顺利,只是忘了装桌面…嘛,反正也用不上,而且 Fedora 的命令行界面比 ArchLinux 要好多了,有彩色文字,还能占满整个屏幕,不像 ArchLinux 无法自适应分辨率,只有屏幕中央 800x600 的一小块。
Linux Mint
上面那组图真是万能,这 Mint 完全就是 Ubuntu 套个壳 Windows UI 的壳…更神奇的时,命令行工具长得和 cmder 好像…
安装过程比 Fedora 还傻瓜,但这也不好,没法选择基础工具的安装,比如后文中我就遇到了缺少python3-dev
的问题。
基础设施
一开始用的 Fedora 桌面版,很多东西都没装;之后用命令行版,倒是因为勾选齐全,可以开箱即用。
重点记一下 Fedora 桌面版在使用 gcc 编译前的一些工作。
编译 zimg 的流程如下,和编译 VapourSynth 一样。
1 |
|
在此之前,需要安装
1 |
|
逐个说一下
- 无 autoconf,
autogen.sh
脚本无法运行 - 无 automake,运行
autogen.sh
报错缺少aclocal
。 - 无 make,呃…这个你懂的
- 无 libtool,在执行
make
命令时,报错1
error: Libtool library used but 'LIBTOOL' is undefined
- 无 gcc-c++,在执行
make
命令时,报错1
error: A compiler with support for C++11 language features is required.
基础设施 Plus
构建与编译工具
回看之前的编译 VapourSynth 的博文,才记起之前接触过 autoconf、automake、libtool。这才意识到,autoconf 和 automake 是用于构建的通用工具,而libtool则是编译依赖。
gcc-c++
是红帽家(CentOS、RedHat、Fedora)yum 包管理器中的名字,在 Ubuntu、Mint 系的 apt-get 下叫g++
。
在Linux Mint下编译VapourSynth,报错
1 |
|
这是因为缺少python3-dev
,在红帽家的 yum 系中叫python3-devel
。
关于 zimg
在 ArchLinux 下,居然能用 pacman 安装 zimg,我记得我在 ArchLinux 编译VapourSynth没有编译 zimg 的过程,就是通过 pacman 安装的。
顺带,这里有必要区分下 zimg。我自己所提到的 zimg,包括这篇博文与之前编译 VapourSynth 时用的,都是指 sekrit-twc/zimg 项目,这是图像处理库,提供了位深转换、色彩空间转换、缩放功能,ArchLinux 的 pacman 包管理器提供的 zimg,也是指这个;而在另一些语境下,zimg 则是指 buaazp/zimg,这是图像存储与处理系统。
回到size_t
这次的折腾缘起于上面 Issue 中 gcc 10 对size_t
报错,但我尝试之后,没有报错…
于是搜了一下类似的报错(自定义了类型size_t
,却被编译器认为是std::size_t
忘了写std
),原来由来已久,我还以为的 gcc 10 支持了什么新特性,导致代码冲突呢…
搜了下,也是一笔糊涂账,可能是编译环境中有什么问题导致的,先不管了…
写完才发现跑题了…那我也溜了吧…Orz
Makefile 相关
既然跑题了,再塞点东西。
根据这篇博文 Makefile/Makefile.am/Makefile.in 三者关系,可以梳理一下使用 make 构建和编译的流程。
创建工作目录
写代码
生成
configure
- 在 zimg 中借助脚本,也就是这样一行命令
1
autoreconf --verbose --install --force
- 手动的话要借助
aclocal
和autoconf
命令,分别会产生aclocal.m4
及configure
- 在 zimg 中借助脚本,也就是这样一行命令
写
Makefile.am
使用 automake 生成
Makefile.in
执行
configure
生成Makefile
执行
make
编译