CentOS

CentOS 7交叉编译调用libsamplerate库程序ARM64(aarch64)版的libm wrong format问题

2024年12月17日 0, ? C, C++, Obj-C 设计开发 软硬件使用

还是先说下环境，系统是CentOS 7.9（怕玩坏了，用的docker，官方镜像centos:centos7.9.2009），配合ARM官方的linux工具链gcc-arm-8.3-2019.03-x86_64-aarch64_be-linux-gnu.tar.xz（这里： https://developer.arm.com/downloads/-/gnu-a），解压到了 /usr/local/ARM-toolchain/gcc-arm-8.3-2019.03-x86_64-aarch64-linux-gnu，使用环境变量：

export AR="/usr/local/ARM-toolchain/gcc-arm-8.3-2019.03-x86_64-aarch64-linux-gnu/bin/aarch64-linux-gnu-ar"
export AS="/usr/local/ARM-toolchain/gcc-arm-8.3-2019.03-x86_64-aarch64-linux-gnu/bin/aarch64-linux-gnu-as"
export CC="/usr/local/ARM-toolchain/gcc-arm-8.3-2019.03-x86_64-aarch64-linux-gnu/bin/aarch64-linux-gnu-gcc"
export CXX="/usr/local/ARM-toolchain/gcc-arm-8.3-2019.03-x86_64-aarch64-linux-gnu/bin/aarch64-linux-gnu-g++"
export RANLIB="/usr/local/ARM-toolchain/gcc-arm-8.3-2019.03-x86_64-aarch64-linux-gnu/bin/aarch64-linux-gnu-ranlib"
export STRIP="/usr/local/ARM-toolchain/gcc-arm-8.3-2019.03-x86_64-aarch64-linux-gnu/bin/aarch64-linux-gnu-strip"
export PATH="/usr/local/ARM-toolchain/gcc-arm-8.3-2019.03-x86_64-aarch64-linux-gnu/bin:$PATH"

来指定交叉编译工具链，依赖的libsamplerate库版本是：0.2.2，报错信息如下：

/usr/local/ARM-toolchain/gcc-arm-8.3-2019.03-x86_64-aarch64-linux-gnu/bin/../lib/gcc/aarch64-linux-gnu/8.3.0/../../../../aarch64-linux-gnu/bin/ld: /usr/lib64/libm.so: error adding symbols: file in wrong format

Continue reading…

CentOS 8运行其它环境编译的curl报77错误解决方法

2021年12月4日 0, ? C, C++, Obj-C 设计开发 软硬件使用

此问题来源于经过Github Actions编译出来的curl执行程序，由于actions默认的构建环境都是Ubuntu的，编译构建出来的新版本curl放到CentOS 8上运行时，会提示类似如下内容的错误（仅限需要用到ssl证书的协议，如https）：

curl: (77) error setting certificate verify locations:
  CAfile: /etc/ssl/certs/ca-certificates.crt
  CApath: none
...
curl: (77) Error reading ca cert file /etc/ssl/certs/ca-certificates.crt - mbedTLS: (-0x3E00) PK - Read/write of file failed

按照网上搜到的说法，重新yum安装ca-certificates之类的都不起作用，查看/etc/ssl/certs目录，发现有如下内容：

Continue reading…

CentOS 7通过yum安装GDB 8的方法

2019年05月4日 1, ? 软硬件使用

最近又在研究远程C/C++项目的linux远程编译调试方法，之前写过一个VS结合VisualGDB搭建OpenWrt交叉编译远程调试开发环境，虽然最终目标平台是OpenWrt，但也算是远程linux编译调试，不过VisualGDB是VS的插件，而且现在新版VS（我看的是2017）已经开始自带支持linux开发了，通过cmake创建编译配置，并且允许在远程linux系统上编译调试：
https://docs.microsoft.com/en-us/cpp/linux/connect-to-your-remote-linux-computer?view=vs-2017，虽然看起来比VisualGDB还差太远…不过，这次的重点并不是VS，因为VS只支持windows（我知道有Mac版了，但是呵呵，那并不是我认识的VS），而对Win和Mac作为远程linux开发host都可以支持的IDE还是有的，那就是JetBrains系的CLion！

然而，不幸的是，在我的CentOS 7 slave虚拟机里，发现CLion需求的remote debug用的GDB版本（ 7.8.x-8.2.x ）并不能满足（7默认yum装的是7.6），那么问题就变成给CentOS 7装个新版本的GDB了…

Continue reading…

CentOS 7下自编译、打包RPM最新版Apache2 (httpd 2.4.37) 并开启HTTP/2

2018年11月10日 0, ? 软硬件使用

之前一直没什么时间研究新东西，博客上写的也都是些没啥滋味的东西，今天记录的这个应该能算是有些滋味的吧，不过，在正文之前，先写点铺垫，为啥现在研究起http 2.0了？这个h2吧，其实很早以前就听说过，各种好吧就是，但之前一直都有一种还很理论还很遥远的感觉，直到最近研究Google GRPC的Web实现gRPC-Web(有兴趣的话，传送门在这里：https://grpc.io/docs/quickstart/web.html)时，发现其中用到了一个叫envoy的转发代理服务器(https://www.envoyproxy.io/)来实现gRPC传输层需要的h2协议，突然感觉h2要开始普及了，查了下资料，发现h2的server push设计很有吸引力(其间还找到个这个网站：https://http2.akamai.com/demo，直观的演示了http 1.1和2.0的差距)，于是乎萌生了测试下h2用在普通网站服务器的想法。

一开始还觉得现在是不是主流Web服务器都支持http2了，一查发现本博用的lighttpd还没有加入http2的支持，而apache和nginx已经有稳定支持版本了，又搜索了下网上的评论，发现还是Apache跟的比较紧，所以就从老朋友Apache入手尝鲜吧。

我的测试环境是装在虚拟机里的CentOS Linux release 7.5.1804 (Core)，直接yum安装httpd的话是2.4.6-80.el7.centos.1 这个版本，而Apache是从 2.4.17 才开始支持mod_http2正式支持h2的，残念之后习惯性的找各种第三方rpm源，看是否有能直接撞的2.4.17以上版本，结果发现虽然是有，但是很少，而且也不是特别新的版本(另外这里https://www.mf8.biz/apache-httpd-%E5%BC%80%E5%90%AF-https-%E5%92%8C-http2/也提到”截止发文切仍受支持的 RHEL、CentOS 5、6、7 均不提供 Apache Httpd（apache2） ≥ 2.4.17 和 OpenSSL ≥ 1.0.2 的支持，也没有提供支持的第三放软件源支持。”)，于是就想不行就自己直接拿源码装吧。其实，如果只是拿源码装的话应该是挺简单的，要啥编啥就得了，不过我这还有个需求就是想把编译好的新版apache方便的装到远端VPS上测试，当然VPS也是CentOS的，所以就变成了不止要自编译还要打包RPM了…

Continue reading…

CentOS 7 yum update中断重启后提示kernel panic-not syncing:VFS:Unable to mount root fs on unknown-block

2016年12月25日 0, ? 软硬件使用

今天更新VMWare上的CentOS 7时，不小心手滑在安装进行到一半左右时关掉了ssh连接，结果再回来时yum就不好了，显示提示有中断的操作，然后又是multilib，一通cleanup之后yum是不提示异常了，结果reboot后直接kernel panic异常，系统无法启动！

好在bootloader里的rescue还是可以进的，搜索了一下测试了下，最简单的解决方法是先

sudo yum remove kernel

再

sudo yum install kernel

然后再重新启动正常的kernel就可以进系统了，不过感觉由于yum update时中断导致的某些软件丢失或是版本不对的问题还是存在，等到用时再逐一解决吧。

内网Visual Studio Code通过XDebug远程调试linux服务器PHP脚本

2016年10月27日 2, ? 设计开发 软硬件使用

开发环境是这样：一台位于内网环境下的Windows机器使用VSCode作为IDE编写PHP脚本项目，一台位于公网的linux服务器运行lighttpd、fastcgi PHP用于部署调试。开发机所在网络环境不允许或不方便进行端口映射来打开XDebug所需的本地调试监听端口（默认9000），同时也不想安装本机PHP服务器来调试，于是采用本机编写PHP，然后上传linux服务器直接远程调试，记录环境搭建过程如下：
首先配置好开发机的IDE环境，我用的是VSCode 1.6.1，然后安装PHP Debug扩展，完成后选择一个指定文件夹作为项目根目录并在调试页中新建PHP调试配置，这时会在项目文件夹中生成.vscode/launch.json配置文件，按照PHP Debug的说明，加入serverSourceRoot与localSourceRoot，参考如下：

{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "Listen for XDebug",
            "type": "php",
            "request": "launch",
            "port": 9000,
            "serverSourceRoot": "/var/www/lighttpd/phpproj",
            "localSourceRoot": "${workspaceRoot}"
        },
        {
            "name": "Launch currently open script",
            "type": "php",
            "request": "launch",
            "program": "${file}",
            "cwd": "${fileDirname}",
            "port": 9000,
            "serverSourceRoot": "/var/www/lighttpd/phpproj",
            "localSourceRoot": "${workspaceRoot}"
        }
    ]
}

其中serverSourceRoot为项目位于服务器端的存储位置完整路径，localSourceRoot为本地项目存储位置完整路径，一般用环境变量${workspaceRoot}即可表示项目根目录。
Continue reading…

CentOS 7下编译FBX SDK示例时的”cannot find -luuid”问题

2016年07月28日 0, ? C, C++, Obj-C 设计开发

在Linux环境下尝试编译FBX SDK中的samples时，最后链接时出现”cannot find -luuid”，查了下文档发现这个uuid库是linux下生成唯一id用的那么一个库，起初以为是少了什么lib或者devel之类的，于是用yum开始安装，结果libuuid、uuid-devel都装上了还是不行，于是又都逐一卸载掉，查看ld的search path，在/lib64/下找到了：

lrwxrwxrwx. 1 root root 16 4月 7 22:35 /lib64/libuuid.so.1 -> libuuid.so.1.3.0
-rwxr-xr-x. 1 root root 20032 4月 1 01:37 /lib64/libuuid.so.1.3.0

用yum确认了下，也确实是已安装有这个uuid相关的库以及include等，于是怀疑是符号链接的问题，试了下用

ln -s libuuid.so.1 libuuid.so

建立libuuid.so的符号链接，重新make，成功通过并生成了sample的执行文件。

PS: FBX SDK的sample中的MakeFile将CC和LD设置成了gcc4，这个在我的CentOS7下会找不到（默认安装的应该都是），于是直接删掉了4。

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

2015年11月12日 1, ? C, C++, Obj-C 设计开发

本文记录的方法理论上适用于所有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…