编译

记录Mac系统下构建FFmpeg(-Wl,rpath不支持)及依赖库libxml2遇到的两个问题

最近在Mac系统下尝试编译FFmpeg源码,虽然由于都是nix系的系统,比Win下编译方便很多,但还是遇到一些由于系统差异导致的问题。首先是依赖库libxml2编译时,提示:

-bash: libtoolize: command not found

这个问题,简单调查后发现是由于Mac系统已经存在libtool这个工具,但是功能不同,而相同功能的工具程序换了个名字,叫glibtool,可以通过brew安装,参考这个地址:https://stackoverflow.com/questions/15448582/installed-libtool-but-libtoolize-not-found

glibtool可用后,增加个符号链接,或者改下libxml2的构建脚本,就可以build成功了。

第二个要记录的问题是FFmpeg在编译时,由于使用的是Xcode命令行工具安装的clang,无法识别gcc的“-Wl,rpath=”链接命令,用于指定rpath。

这个问题参考这个github上的issue描述:https://github.com/klee/klee/issues/591,将指定rpath链接参数的写法换成“-Wl,-rpath xxx”即可,多个rpath路径时可以参考下Xcode项目设置里增加rpath后生成的编译链接命令写法。

使用Win10 + WSL编译FFmpeg时的依赖库处理

Windows 10的Linux子系统WSL安装过程就不做赘述了,网上资料很多。

之前一直认为WSL只是以类似虚拟机或容器化的方式使得能在Windows上运行原生Linux程序,当然,也在WSL上做过如使用ndk交叉编译Android原生程序、动态库的操作,用起来还是挺方便的。直到最近研究FFmpeg的Windows版编译时才发现(参考自:https://www.bilibili.com/read/cv7058269/),原来WSL还有一个“大杀招”:直接运行Windows执行程序exe,如下图所示:

可以看到,在WSL内直接执行VS 2019的编译器程序cl,也是完全没有问题的,基于这种方法,FFmpeg官网上所说的用cygwin,mingw,msys之类的桥接环境构建Win版FFmpeg的麻烦就不复存在了,而且新版FFmpeg源码(博主用的4.3)的configure也做好了对这种编译方式的支持,参考上面的链接,制定上toolchain=msvc等相关参数,剩下的事和nix系统上构建一样就可以顺利完成了,简单方便!

不过,今天要记录的并不是WSL下编译Win版FFmpeg的问题,而是编译时如何引入其它依赖,如openssl,xml2等以获取更多功能支持,尤其是在Win环境下,这些其它依赖库的位置很有可能是一个很随意的位置,而在WSL环境下处理这种依赖的头文件、库文件搜索路径时是有坑的…

Continue reading…

64bit Linux CentOS 7下编译32bit程序的方法

本文记录的方法理论上适用于所有RedHat系Linux发行版!
一般在64位Linux下(安装好gcc等相关编译工具后)编译出的执行程序都是针对64位环境的,如果想编译为针对32位环境的(当然,64位系统环境下也可以兼容运行),只需要在执行gcc时加上-m32编译即可(ld的话也有对应参数-melf_i386),虽然编译时只是加参数即可,但仍然有c、c++标准库等需要首先安装好32位相关版本。
如下,如果直接-m32编译的话,会收到如下错误提示:

[kres@localhost test6432]$ gcc -m32 test.c
In file included from /usr/include/features.h:399:0,
from /usr/include/unistd.h:25,
from /usr/include/usb.h:28,
from test.c:1:
/usr/include/gnu/stubs.h:7:27: 致命错误:gnu/stubs-32.h:没有那个文件或目录
# include ;
^
编译中断。

Continue reading…