移动库和头文件

我有一些c代码，它提供了libfoo.so和libfoo.a以及头文件foo.h.大量的客户端目前使用这些来自/ old_location/lib和/ old_location/include目录的库，这些目录是它们被分配的地方。移动库和头文件

现在我想将此代码移至/ new_location。然而，我无法告知客户这种变化。我希望旧客户端继续访问/ old_location中的库和头文件。

为此，将创建符号链接到libs /头到新的位置工作？

/old_location/lib/libfoo.so -> /new_location/lib/libnewfoo.so 
/old_location/lib/libfoo.a -> /new_location/lib/libnewfoo.a 
/old_location/inlcude/foo.h -> /new_location/inlcude/foo.h

[请注意，我需要来命名新的lib为lib中新 foo和由于某些限制不libfoo的。这个重命名可以导致任何问题吗？然而，生成这些代码的C代码没有改变。]

它似乎适用于我试过的几个简单案例。但是，在有些情况下，客户使用库和头文件的方式可能会因此更改而崩溃。请让我知道这可能涉及什么样的错综复杂。对不起，如果这似乎是一个新手问题，我以前几乎没有与c工作过，并且是一个java人。

来源

2010-01-14 baskin

您必须区分编译时间和运行时间。

对于编译时，客户端需要更新他们的Makefile和/或配置逻辑。

对于运行时，您只需通过通过ld.so.conf了解在哪里可以找到.so库（或者告诉客户调整LD_LIBRARY_PATH，这是第二个最佳选择）。静态库不重要，因为它的代码已经内置到可执行文件中。

是的，通过提供符号链接，您可以使移动“消失”，并通过旧位置提供所有文件。

而且所有这些都是在推出之前从您的结尾进行测试。

来源

2010-01-14 13:36:19

感谢德克响应。我特别关心将库从libfoo重命名为libnewfoo。你认为这是否会造成麻烦？ – baskin 2010-01-14 13:50:32

是的，如果客户端使用动态链接，那么很可能会破坏_run time_。 – 2010-01-14 14:40:46

我没有看到任何理由为什么这会中断，这是一个关于符号链接比C的问题。对于一个不知情的用户程序（没有特殊代码来检测符号链接和抱怨），符号链接是透明。

如果您遇到错误，请随时发布，我们将尽我们所能提供建议。然而，我看不出任何会导致问题的东西。

来源

2010-01-14 13:38:21

符号链接可以在任何支持符号链接的操作系统和文件系统上运行。

来源

2010-01-14 13:38:46

符号链接的唯一问题可能是，如果某些客户端使用不同的路径装载新位置，这可能在联网的unix类型环境中。例如，你可以有位置为：

/var/stuff/new_location/include/...

和客户端可以安装作为：

/auto/var/stuff/new_location/include/..

在这种情况下，相对的符号链接可能会更好地工作，即：

old_location/include/foo.h -> ../new_location/include/foo.h

另一个要考虑的是更换OLD_LOCATION/foo.h中有：


/* 
* Please note that this library has moved to a new location... 
*/ 
#include "new_location/include/foo.h"

来源

2010-01-14 13:57:44

移动库和头文件

回答

相关问题