gcc

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…

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

2024年09月7日 0, ? C, C++, Obj-C 设计开发

首先说明下代码结构：一共三个源码，两个动态库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）

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

之前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系系统的动态库全局函数重名问题

2022年02月11日 0, ? C, C++, Obj-C 设计开发

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

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…

又是wchar_t的问题，这次是Apple LLVM compiler 3.0的bug！

2012年03月7日 0, ? C, C++, Obj-C 移动平台 设计开发

之前发现过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 *

2011年05月18日 0, ? C, C++, Obj-C

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

void foo(char* szArg);

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