CentOS

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

最近又在研究远程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了…

继续阅读…

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

之前一直没什么时间研究新东西,博客上写的也都是些没啥滋味的东西,今天记录的这个应该能算是有些滋味的吧,不过,在正文之前,先写点铺垫,为啥现在研究起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了…

继续阅读…

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

今天更新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脚本

开发环境是这样:一台位于内网环境下的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}即可表示项目根目录。
继续阅读…

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

在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程序的方法

本文记录的方法理论上适用于所有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 ;
^
编译中断。

继续阅读…