C/C++ 编译器如何在缺乏依赖库(只有头文件)的情况下正确编译？

[alphaprogrammer]

一份代码需要编译到几种不同的平台， 依赖一些第三方库，因为没有编译环境，只能采用交叉编译的方式， 有没有方法能解决这种问题？

目前我知道的是通过 dlopen 的方式来处理，但是对代码改动较大，大家有什么其他更好的方法吗？

[alphaprogrammer]

@hitmanx 目前在这方面尝试，dlopen 之类的壳代码不知道有没有什么方法能自动生成的

[alphaprogrammer]

@ysc3839 -_-!! 对 window 不了解，没接触过。

[SPACELAN]

@alphaprogrammer #19 静态兼容性好很多，也方便别人直接运行

[neighbads]

接口不多的话 写个假的 lib，只有导出函数没有功能的。。

[ysc3839]

@alphaprogrammer https://www.cprogramming.com/tutorial/shared-libraries-linux-gcc.html
帮你找到了，Linux 也有这个功能，而且 gcc 可以直接识别 .so 文件，不像 Windows 需要一个 stub lib。

[chinuno]

系统的包管理器不是这样用的。。
那上面的库是为了维护系统内的依赖用的。你要用上面的库应该目标系统上安装 dev 包在目标系统上编译才能用这些库。
另外一种用到包管理器里面库的情况是源维护者自己编译软件包的时候用到，一般也是维护者交叉编译对应库链接过去的。
自己另外编译还强行用这些库很容易依赖被破坏。包管理器安装的软件一般没出问题是因为有维护者一直在更新依赖，就算是这样有时候还是会出现依赖问题。
如果你只是要在对应系统发布可执行程序，最好的做法是每个平台编译对应的静态库，发布的时候发布静态连接的可执行程序。如果需要源码发布就附带每个平台的静态库一起发布。

[augustheart]

@alphaprogrammer 甚至平台不同也会碰到问题的。每个平台的实现可能不同。基本上来说就是靠运气编程

[FrankHB]

@SPACELAN 静态链接兼容性一样要看节操，谁给你保证更好的。
更没法变通才是真的。
另外 Win32 上嘛，静态库里糊个 main 进去还可能让链接器找不到入口……

[FrankHB]

Ubuntu 用的第三方库，本来就没给你打算交叉编译来用。问题是你自己搞不到源码直接自己编译？
退一步讲，就这些库的节操……真用，跑个虚拟机搞个环境都比你搞交叉编译省事。

[SPACELAN]

@FrankHB #28 参考 Golang

[alphaprogrammer]

说一下情况，就是原本写的代码时基于 x86 的，现在需要在 arm 上跑，依赖于一些第三方库(在目标机上可以直接 apt 安装)。目前由于没有 arm 环境，只能在 x86 上使用交叉编译的方式编译出 arm 可执行程序，第三方库依赖采用 dlopen 的方式去除依赖。（如果能下载 arm 版的第三方库 binary，也可以直接编译的）

目前我的实现方式有点取巧，个人感觉实现方式不太好。

首先，之前实现的代码都定义在一个 namespace A 下，
假定依赖一个 func_b，其类型为 type_func_b, 在 namespace A 下定义一个 type_func_b 的变量 func_b，变量名与函数名相同，通过__attribute__(constructor)初始化 func_b 变量，指向第三方库中的函数符号。

这样以前的代码基本不需要改，只需要根据编译 include 一个头文件即可。
有一个缺点就是必须定义在同一个 namespace 下，否则变量 func_b 会与第三方库中的函数声明冲突