能写这基础的都是特别厉害的👍

其实不是的啊

只是包装了一下bubblewrap

感谢分享哦~

版主大佬，我今天用你这个工具折腾了一下数位板驱动，然后发现几个可以改进的地方

首先是我看包里默认的libc版本比较高，所以我自己找了合适版本的libc-bin然后解包，但是通常deb或者rpm里都是带有目录结构的，而ablrun自带的是扁平的

然后ablrun我理解的是默认只会替换libc.so.6、ld-linux-x86_64.so.2、ldd这几个，再加上LD_LIBRARY_PATH添加了glibc的lib目录。这里就碰到问题了，libm还有其他许多glibc编译出的so应该也是需要替换的

所以一番碰壁后，我把这个脚本改了下，主要是在给定的一个root下面找libc的所有symlink，然后把symlink对应的实际文件映射到那些symlink下面，比如 --bind /usr/lib/x86_64-linux-gnu/additional-base-lib/libc_2_29/lib/x86_64-linux-gnu/ld-2.29.so /lib/x86_64-linux-gnu/ld-linux-x86-64.so.2

    prefix=/lib/x86_64-linux-gnu
    files=`ls $ABL_ROOT/$prefix`
    echo $files
    for file in $files
    do
        echo $file
        if [ -L $ABL_ROOT/$prefix/$file ]
        then
            real=`readlink -m $ABL_ROOT/$prefix/$file`
            echo $file'=>'$real
            binds+="--bind $real $prefix/$file "
            # echo binds=$binds
        fi
    done

    # echo $binds
    exec bwrap --dev-bind / / bwrap \
    --dev-bind / / \
    --bind ${ABL_ROOT}/lib/x86_64-linux-gnu/"ld-2.29.so" "$ABL_LD_SO_PATH" \
    $binds \
    --bind ${ABL_ROOT}/usr/bin/ldd /usr/bin/ldd \
    --setenv LD_LIBRARY_PATH "$ABL_LIBRARY_PATH" \
    --cap-add CAP_SYS_ADMIN \
    -- "$@"

目前的一个问题是Ubuntu、Debian等等的rpath啥的目录结构不同，要是解决了这个，应该就可以直接拿对应系统的deb包来支持多种版本了

在ld.so的动态库加载顺序里面LD_LIBRARY_PATH只低于写死在程序里面的DT_RPATH，而且这个特性已经被弃用了，现在应该是用DT_RUNPATH和DT_NEEDED共同决定，而且这一项的优先级是低于LD_LIBRARY_PATH环境变量的（可以阅读man ld.so）。所以在大多数情况时这样做已经足够了。其实确实有些程序，会在脚本里面覆盖掉LD_LIBRARY_PATH导致失效，我也考虑过要不要把所有库都挂载替换掉，但是总觉得不太干净。其实挂载libc.so才是比较无奈的，因为如果不这样做ld.so就不能运行（他俩是必须配套的）。ldd其实对于运行程序来说是无关紧要的，只是这个脚本在获取信息的时候很管用，而且我确实发现不同版本的有兼容问题。

第二个是glibc是向后兼容的，现在还没发现有必须要旧版本libc才能运行而新版本运行不了的程序，所以通常情况是只用最新版本就可以了。因此我没有做多版本共存的设计。debian的版本也不是很新，但是我认为用他的东西比较稳妥。如果需要更新版本的，也可以用我的自动打包脚本。

第三个是我自己研究过了不少发行版，其实同一套包管理系统的目录结构是没有差异的。比如说dpkg系，debian和ubuntu的目录结构是没有区别的，只是系统中可能有一些文件的包名不一样。debian的文件结构规范是一种，而rpm系是另一种（大体就是Linux基金会的LSB规范），其他arch、slackware等发行版又有微妙的区别，但是我自认为我制作的包能适应多数流行的dpkg和rpm发行版的要求。

很感谢你的关注，我也不很专业，主要就是提供一个想法，大家可以随意应用。关于这个程序有任何问题都可以拿来讨论。我暂时还不知道是不是很需要改，如果对你的困惑能描述地更清晰一些，或者把你需要运行的程序让我看看，我也许会改变主意。

论坛貌似没给我显示消息通知所以一直没看到XD

我看了你说的之后对动态装载的认识更加正确全面了，很同意你的想法

但是我这个程序确实跑着就很奇怪，ldd相应的elf显示是正确的（引用了LD_LIBRARY_PATH下的so），但直接运行就会去引用default path下面的so。

刚才我又看了下，确实是你说的那种情况，这个程序是个跨平台的外设驱动，运行脚本里会把LD_LIBRARY_PATH设置成自己的libs目录，所以libc就只会从default path找了

additional-base-lib_2.38-13-9_amd64.deb

root@YUN-PC:/# ablrun SecureCRT
SecureCRT: error while loading shared libraries: libssl.so.1.1: cannot open shared object file: No such file or directory

大佬DeepinV23RC2不能运行SecureCRT，求更新库。。。

我觉得网上的办法不靠谱，居然让我安装openssl1.1

https://bbs.deepin.org/post/274982

这个我觉得不涉及ablrun的

如果系统软件源里有openssl-1.1或者libssl-1.1安装上就行了，没什么风险。如果系统软件源没有的话，不要安装来路不明的软件包，也别乱添加别的软件源。看看星火商店有没有这个软件，改用星火商店的版本就好了。