CoderWkm 写了: ↑2023-10-30 11:57
我已经把对应的32位regex库的文件放在的ld搜索的默认路径/usr/lib/x86_644-linux-gnu下
你用make时,传递给cc的参数没有包含-m32,是在编译针对当前平台的64位程序,你给个32位的库是没用的。
另外,你传递-labc这种参数给gcc时,gcc会依次去寻找1)当前目录下名为-labc的文件,2)各库文件目录下名为libabc.so的文件,3)各库文件目录下名为abc.a的文件。所以你要复制的话,不能光复制带版本号的libabc.so.1.2.0,要么你把它更名为libabc.so,要么建立个软链接libabc.so指向它。
还有啊,我看你都在从源码重新编译了,那干嘛不干脆编译出一个依赖boost 1.71的64位程序呢?你开头就来编译boost,我还以为没源码只剩个可执行文件了
CoderWkm 写了: ↑2023-10-30 11:57
最后一个就是,关于这种linux下C/C++的编译环境问题,您有没有什么好的学习建议?别人之前推荐我学习一下docker,希望前辈不吝赐教!
我的建议是去查官方文档。流行的项目在这方面的文档一般都做得不错。对那些没提供文档的,记住一些最基本的概念及相关的专业英文词汇,到google上用英文搜一下。就那你这个boost的例子来说,我看到你的帖子,就猜到应该是交叉编译的问题。然后下了个boost的代码,看到它用的编译构建系统我不认识,然后上google搜boost cross compile就搜到了那篇官方文档,然后从文档里找到了配置方法。
docker这种容器化方案,解决的是部署环境一致性的问题。你这种在旧系统上可以运行,在新系统上缺这缺那也算是部署环境不一致导致的。但docker和其他一些容器化技术主要是针对服务,一般的应用程序可以用ubuntu家力推的snap、redhat推的flatpak、或者appimage。
反正这些技术的核心思想说白了就是把可执行程序和它所有依赖的东西带在一起,这样就不会缺了。不用这些花里胡哨的,自己手动把相关依赖带上也是一样的。至于上面那些提供的沙盒化功能,一般应用也不怎么需要。新人的话,最好先把这些基础的原理性的东西搞清楚,再看这些技术也没啥神秘的了