我有一些c代码，它提供了libfoo.so和libfoo.a以及头文件foo.h.目前，大量客户端使用/ old_location / lib和/ old_location / include目录中的这些库，这些目录就是它们所在的目录。
现在我想将此代码移至/ new_location。但我无法告知客户这一变化。我希望旧客户端继续从/ old_location访问libs和头文件。
为此，为新位置的libs / headers创建符号链接是否有效？
/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 new foo而不是libfoo。这个重命名会导致任何问题吗？然而，生成这些的C代码没有改变。]
这似乎适用于我尝试过的几个简单案例。但是，在某些情况下，客户端会以某种可能因此更改而中断的方式使用lib和头文件。请告诉我这可能涉及哪些错综复杂的问题。对不起，如果这似乎是一个新手的问题，我以前很难使用c，而且我是一个java人。
答案 0 :(得分：2)
您必须区分编译时和运行时间。
对于编译时，客户端需要更新其Makefile和/或配置逻辑。
对于运行时，您只需通过ld.so通过ld.so.conf告诉您在哪里找到.so库（或告诉您的客户调整LD_LIBRARY_PATH，这是第二个最佳选择）。静态库无关紧要，因为它的代码已经内置在可执行文件中。
是的，通过提供符号链接，您可以使移动'消失'，并通过旧位置提供所有文件。
在推出之前，所有这些都是可以测试的。
答案 1 :(得分：1)
我没有看到任何理由为什么会破坏，这更像是一个关于符号链接而不是C的问题。对于一个毫无戒心的用户程序（一个没有特殊代码来检测符号链接和抱怨），符号链接是透明的
如果您遇到错误，请随时发布，我们会尽力提供建议。但是，我没有看到任何可能导致问题的问题。
答案 2 :(得分：1)
符号链接的唯一问题可能是某些客户端使用不同的路径挂载新位置，这在联网的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"
答案 3 :(得分：0)
符号链接适用于支持符号链接的任何操作系统和文件系统。