gcc

linux系统gcc编译动态库so中的attribute((weak))弱符号使用

首先说明下代码结构:一共三个源码,两个动态库so的源码:lib1.c和lib2.c,各导出一个库函数(gcc编译时默认导出,不像windows的msvc要明确指定导出dllexport),一个主执行程序源码:main.c,调用两个动态库的导出函数,如下:

lib1.c

#include <stdio.h>

void lib1_func(const char* from)
{
        printf("lib1 func from %s\n", from);
}

lib2.c

#include <stdio.h>

void lib2_func(const char* from)
{
        printf("lib2 func from %s\n", from);
}

main.c

#include <stdio.h>

void lib1_func(const char* from);
void lib2_func(const char* from);

int main()
{
        printf("hello from main\n");
        lib1_func("main");
        lib2_func("main");
        return 0;
}
Continue reading…

Win下搭建CLion配合远程Linux的联盛德W801开发环境(csky-elfabiv2-tools)

之前9块钱促销买了块海凌科(Hi-Link)的W801开发板HLK-W801-KIT-V1.1:

到手后看了各种资料用CDK IDE搭起了开发环境,简单试了试灯,还踩了个Upgrade Tools上传程序的坑:W801开发板Upgrade Tools上传程序失败问题,那之后这块板就吃灰了😂,最近因为发现网口WOL网络唤醒在电脑完全断电恢复后无法使用的问题(试了自己和朋友的几台电脑,华硕的x370主板、技嘉的x570主板、公司的技嘉z390主板都不行,网上看有人说自己的电脑可以掉电后WOL,介绍的各种设置方法也基本都试了个遍,无果), 打算研究个IoT远程开机功能,嘉立创的开源平台上一搜能搜到很多,但大都基于ESP的MCU,于是又想起了这块W801…不过用惯了VS、Xcode、CLion的我对之前使用CDK的体验着实不怎么样,在联盛德的官方论坛上也看到有人基于VSCode搭建了开发环境,有win下配msys的,也有走远程linux编译的,由于本人实在是对cgywin,mingw这类windows下移植linux环境的工具不感兴趣,所以这回打算尝试下远程linux编译的方式再次搭建下W801的开发环境,同时使用最近经常用的CLion IDE(我用的Nova版,写此文的时候还处于EAP状态,已经进入RC状态了,下载2024.1 RC版(设置中高级里启用ReSharper 引擎,重启后就是Nova办了),但实际测试并没发现什么严重问题,理论上稳定版对远程linux开发支持应该也是一样的),另外,多说一句,虽然说的是remote linux,其实WSL,或者本地虚拟机也都是一个道理,那下面我就记录下这样搭环境的主要步骤。

Continue reading…

关于linux系系统的动态库全局函数重名问题

最近在使用某几个知名厂商的对象存储C SDK时,发现由于这些SDK的内部实现其实基本是一样的,进而导致了各个SDK的so中都或多或少有些被大家共同喜爱的全局函数(符号)名称,最后引发了在部分环境中出现了调用A厂商SDK的上传函数时崩溃在了B厂商SDK的同名全局函数中的问题,最开始感觉很是莫名其妙,后来查了资料发现,首先gcc编译时默认会将全局变量、函数等符号导出在都动态库中,而同时全局函数的加载又是抢占式的,这点通过如下简单试验便可验证:

Continue reading…

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 ;
^
编译中断。

Continue reading…

又是wchar_t的问题,这次是Apple LLVM compiler 3.0的bug!

之前发现过Android上NDK对wchar_t以及相关函数的支持不足问题,后来又发现过iOS上类似的setlocale问题。最近在更新了Xcode 4.2以后,发现之前用的wchar_t相关的东西都不对了,wcslen函数返回的字符串长度不对,而且在gdb中用p查看const wchar_t*变量时,显示的是const void*,貌似就没有wchar_t相关的东西。

这个问题如果切换编译器为之前的LLVM GCC编译器则一切正常,浪费了很多时间排查错误,最后发现更新了最近的Xcode 4.3(4E109)带的Apple LLVM compiler 3.1就没问题了。啊!原来是3.0的BUG。

deprecated conversion from string constant to char *

可能是xcode4用的gcc版本比较高的原因,在移植代码的时候出现了这样一个警告,正好提高了一下对const char*的认识。

void foo(char* szArg);

这样的函数这样 foo(“test”); 调用就会提示这个警告,以前可能没太注意过,因为传递的参数字符串是被作为常量处理的,而函数原型却要得不是const指针,也就是说函数内实现是允许修改指针内存的,所以编译器就爆了,理所应当的一个warning,改成const char*参数类型就可以了。