C++ gcc-L命令混乱_C++_Gcc - Fatal编程技术网

C++ gcc-L命令混乱

c++ gcc

C++ gcc-L命令混乱,c++,gcc,C++,Gcc,假设我有一个共享库文件，libdemo.so，其中libdemo.so是最终的链接器如果我想构建可执行文件，并且库文件位于当前工作目录中，我将使用-L.-ldemo标志将其链接但是当我运行可执行文件时，除非我指定库路径，LD\u library\u path=。，否则可执行文件找不到链接。那么，为什么需要额外的LD\u LIBRARY\u PATH设置呢？标志用于链接时库路径，环境变量是运行时库路径或者，如果我构建可执行文件并使用-Wl，-rpath，.指定运行时库路径，我可以省略-L.-

假设我有一个共享库文件，

libdemo.so

，其中

libdemo.so

是最终的链接器

如果我想构建可执行文件，并且库文件位于当前工作目录中，我将使用

-L.-ldemo

标志将其链接

但是当我运行可执行文件时，除非我指定库路径，

LD\u library\u path=。

，否则可执行文件找不到链接。那么，为什么需要额外的

LD\u LIBRARY\u PATH

设置呢？标志用于链接时库路径，环境变量是运行时库路径

或者，如果我构建可执行文件并使用

-Wl，-rpath，.

指定运行时库路径，我可以省略

-L.-ldemo

我知道这与链接时间和运行时间有关，但我不清楚两者的区别。例如，当不使用

-rpath

时，如果可执行文件需要

LD\u LIBRARY\u PATH

来查找库文件，

-L.-ldemo

实际上做了什么？当使用后一种方法时，如果指定

-rpath

意味着将目录位置复制到运行时库路径中，为什么还允许省略

-L.-ldemo

如果链接时库路径和运行时库路径不同，为什么后一种方法在构建时不需要链接时库路径？链接时库路径和运行时库路径有什么区别？

因为链接是由两个不同的链接器实例完成的

编译和链接程序时，链接器（如

/usr/bin/ld

会检查外部引用，并通过添加外部引用

libdemo.so

来构建可执行文件

运行程序时，运行时链接器

/lib64/ld-linux-x86-64.so.2

（或者通常说

ld.so

）加载所有需要的共享对象。有几个原因导致未保存

-L

：

不需要
```
libdemo.so
```
位于编译期间的同一路径（因为您可以将二进制文件复制到另一台主机上，该路径是内部构建路径，等等）
它可能不安全，所以
```
ld.so
```
通常会搜索非root用户无法写入的“受信任”路径列表

然而，在某些情况下，保存

-L

会很有用（即安装在

/opt

中的软件），因此Unix的一些引入了RPATH。
经过一些研究（阅读教科书），我找到了我想要的答案
基本上，由于可执行文件不再包含对象文件的副本，它需要某种方法来标识它所需的共享库。在链接阶段，共享库的名称嵌入到可执行文件中，但尚未指定具体位置。所以
-L.-ldemo
实际上只是提供库文件的名称。请注意，在问题中，我说设置
-rpath
时未指定
-L.-ldemo
。这是因为在该命令中，我实际上直接传递了库的名称，
libdemo.so
。如果我没有这样做，那么使用
-L.-ldemo
指定它是必要的
随后将提供运行时库路径，以指定执行时的确切位置