LD_LIBRARY_PATH，Linux中的共享库路径
我写了一个共享对象，然后说说了libsd.so，把libsd.so它的头文件放进sd.h了~/lib。
这是另一个使用libsd.so，比如说的程序test.c，然后像这样编译它：
$ gcc -o test test.c -I~/lib -L~/lib -lsd
然后我test像这样运行：
$ ./test
./test_sd: error while loading shared libraries: libsd.so: cannot open shared object file: No such file or directory
所以我设置了export LD_LIBRARY_PATH=.，然后就可以了。但是，如果我unset LD_LIBRARY_PATH，并把LD_LIBRARY_PATH=~/lib我~/.bashrc的话source ~/.bashrc，再次它没有工作./test，为什么？
export LD_LIBRARY_PATH=~/lib与放入LD_LIBRARY_PATH=~/lib有~/.bashrc什么区别？
问题答案：
如果没有导出，则声明的LD_LIBRARY_PATH仅在脚本（.bashrc）中有效。通过导出，它应该可以工作，但是像这样设置LD_LIBRARY_PATH通常不是一个好主意。
如果您不想在系统路径（例如/ usr / lib）中安装您的库，则可能应该使用一个脚本，该脚本在本地设置LD_LIBARAY_PATH并启动您的应用程序。
-
问题内容： 最近，我们被要求提供其中一个库的Linux版本，之前我们是在Linux下开发的，并已针对Windows发行，而在Windows上部署库通常要容易得多。我们遇到的问题是将导出的符号剥离为仅暴露界面中的符号。想要这样做的三个很好的理由 为了保护我们技术的专有方面，以免通过导出的符号被暴露。 防止用户遇到符号名称冲突的问题。 为了加快库的加载速度（至少有人告诉我）。 然后举一个简单的例子：
-
问题内容： 两个共享库liba.so和libb.so。liba.so使用libb.so。所有c文件都使用-fPIC编译。链接使用- shared。当我们在liba.so上调用dlopen时，它无法在libb.so中找到符号…我们得到“未定义符号”错误。我们可以dlopen libb.so没有错误。我们知道liba正在找到libb，因为我们没有得到文件未找到错误。删除libb.so时，出现文件未找到
-
问题内容： 我正在尝试建立一个共享库。让我们说libabc.so。它使用另一个.so文件，例如lib123.so（/ usr / local / lib中的一个lib）。现在我在我的应用程序中使用共享的liblibabc.so。说我的应用程序。我想知道我应该如何链接这些二进制文件？我不想直接将我的应用程序与lib123.so链接。my- app应该仅与libabc.so链接。我怎样才能做到这一点？
-
问题内容： 我正在从python脚本中调用一个so文件。据我了解，我真的不需要释放使用ctypes在python中打开的共享库。但是，在我的so文件代码中，它dlopen另一个so文件并且不执行dlclose（）。在这种情况下，从python端使用安全吗？我不必释放在ctypes内部加载的共享库soe文件吗？ 问题答案： 始终遵循 “自己清洁后清理 ”的规则（尽管现代技术会为您提供清洁方面的帮助）
-
问题内容： 这是使用g ++ 进行动态共享库编译的后续版本。 我正在尝试在Linux上的C++中创建一个共享的类库。当我尝试使用库中定义的类时，我的问题开始了。我链接到的第二篇教程展示了如何加载用于创建库中定义的类的对象的符号，但是没有_使用_ 这些对象来完成任何工作。 有谁知道用于创建共享C ++类库的更完整的教程，该教程还显示了如何在单独的可执行文件中 使用 这些类？一个非常简单的教程，显示了
-
问题内容： 是否可以使用Go创建共享库（.so）？ 更新 ：为此创建了一个“ 问题 ”。 问题答案： 现在可以使用标志 您需要做的是首先运行以下命令： （以上代码使所有通用软件包都可共享！）然后 最后，在编译代码时，您需要运行： 上面这些就是什么，而不是静态链接所有内容而仅动态链接它们，您最终将获得更小的编译文件。为了让您了解我的带有静态链接的“ hello.go”文件为2.3MB，而使用动态链接