一些背景
是, ia32-libs
在实现真正的多拱之前,这是一个权宜之计 - 基本上,该程序包只包含一堆32位版本的 一些 热门图书馆。
你现在做的是
启用外部架构 i386
在 dpkg
:
dpkg --add-architecture i386
弄清楚这个东西想要什么库并安装适当的32位( i386
)版本,像
apt-get install libfooX.Y:i386
但 注意几个不幸的事情:
Debian中的多拱是基于这样一个事实,即依赖于arch的库被安装到依赖于arch的目录中,例如 /usr/lib/x86_64-linux-gnu
为了原住民 amd64
图书馆和 /usr/lib/i386-linux-gnu/
对于 相同 i386
同一系统上的库。
这里的问题是,第二方软件不知道在Debian中实现的多扩展,通常希望找到依赖于使用类似知名名称的库。 /usr/lib/libfoo.so.X.Y.Z
,最近Debian版本的情况并非如此。
这可以通过符号链接或解决 LD_PRELOAD
或使用其他一些方法搞乱动态加载器(例如,使其使用替代缓存文件而不是 /etc/ld.so.cache
,包含对其他地方安装的库的引用),但请参阅下一点。
关于Linux兼容的Adobe Air版本的工作已经停止了相当长的时间,IIRC,所以最新的Adobe Air blob可能依赖于最近版本的Debian中没有出现的相当过时的库版本。更新的库意味着API / ABI更改,使用符号链接无法解决这些问题。
可能解决方案
如果摆脱这种Adobe憎恶是不可能的,我可能会尝试依赖Linux的事实 内核的 API / ABI非常稳定,并试图创建一个 chroot环境 要么 LXC 环境专门用于使用从任何声称与其兼容的操作系统中提取的库来运行此blob。
基本上,对于chroot,你需要创建一个包含一组最小库的目录(可能是一些二进制文件,比如 /bin/bash
)与众所周知的名字(如 /usr/lib/libfoo.so
)。
这不是一个简单的方法(你需要进行大量的反复试验 readelf
, ldd
,提取和复制文件等)但它可以解决,因为最后,所有库使用系统调用调用内核,并且这些内核版本相当稳定。