对标题感到抱歉，无法想出任何其他描述问题的内容：）
好的，所以事情是这样的：我正在尝试在Linux下使用专有的免费软件应用程序（因此问题;如果我有源代码，我可以重建它）。此外，我正在尝试在不受支持的Linux版本上运行它，并且几乎所有应用程序组件都单独工作，但不能一起工作（如果应用程序完全运行它们应该如此）。
让我澄清一下。有一个GUI，在不受支持的操作系统中启动良好。然后，从这个GUI，您可以调用一堆命令行工具 - 有用的是，GUI也会在每种情况下都会调出命令行。
现在，从GUI调用其中一些命令失败了 - 但是，因为我有实际的命令行调用（比方说：“extprogram -arg1 1 -arg2 2 ...”），我可以从终端重复这些命令行。因此，我发现应用程序作为一个整体带有它自己的libc库;并且使用这些库（某些）命令（从终端运行）往往会失败 - 但是，我发现从命令行开始，这通常适用于失败的那些：
LD_PRELOAD=/usr/lib/libstdc++.so.6 extprogram -arg1 1 -arg2 2 ...
# or alternatively, this works too:
# LD_LIBRARY_PATH=/usr/lib extprogram -arg1 1 -arg2 2 ...
（换句话说，使用系统libstdc ++而不是提供的应用程序，往往会解决问题）
所以，现在如果我能说服GUI用“LD_PRELOAD”/“LD_LIBRARY_PATH”来调用这些工具 - 我想，一切都会正常工作......
不幸的是，GUI没有调用进一步调用这些可执行文件的脚本，我可以直接更改（据我所见，通过grep ping） - 看起来，它是创建系统调用;我试过'strace' - 但是我找不到像临时脚本或任何我可以改变的东西......
所以，我想也许我可以“欺骗”制作一个可执行的bash脚本;所以我移动了可执行文件 - 并创建了一个脚本，该脚本应该调用带有LD_前置的移动可执行文件：
mv extprogram extprogram.old
cat > extprogram <<EOF
LD_LIBRARY_PATH=/usr/lib extprogram $@
EOF
......但这失败了;显然GUI应用程序识别出一些不对的东西。
所以，我在想 - 是否有可能以某种方式，有一个C / C ++代码“包装器”以某种方式“加载”这个可执行文件，但是在一个“LD_LIBRARY_PATH=/usr/lib”的“环境”中set - 并传递它的参数（并返回它的返回值）？然后我可以在操作系统上本地构建这个“包装器”，其名称与原始可执行文件相同 - 并使整个工作正常，而不需要触及原始可执行文件（除了重命名）。
非常感谢任何答案，
干杯！
答案 0 :(得分：9)
你很亲密。你忘记了shebang并使脚本可执行。你也在调用错误的外部程序。最后，我将使用旧脚本的绝对路径，因为您不知道CWD将用于GUI。
mv extprogram extprogram.old
cat > extprogram <<EOF
#!/bin/sh
LD_LIBRARY_PATH=/usr/lib exec /psth/to/extprogram.old "$@"
EOF
chmod +x extprogram
答案 1 :(得分：1)
使用系统libstdc ++而不是提供的应用程序，往往会解决问题
我很想知道使用应用程序提供的libstdc++.so.6导致什么问题，但是如果系统修复了一些问题，那么一个更简单的解决方案是删除（重命名）麻烦的库，而不是做整个shell包装解决方案。
如果应用程序找不到“坏”库，很有可能找到该系统。