在 Windows 上使用 -R 和 -rpath 开关进行链接
我在 Windows XP 上使用 gcc 编译器（MinGW）。我创建了一个 .dll 库 libdir.dll，然后尝试构建一个使用该库的程序。
我不想将该 .dll 文件放入 System 或 System32 文件夹中，也不想在 PATH 变量中设置它的路径，我想要的是将该信息提供给程序本身。
我知道有一个 -R 和 -rpath 开关可用，所以我打算将其与其中之一链接。
第一个-rpath：
gcc -L/path/to/lib -Wl,-rpath,/path/to/lib main.o -ldir -o prog比-R：
gcc -L/path/to/lib -Wl,-R,/path/to/lib main.o -ldir -o prog
这成功链接到 prog，但是当我启动该程序时，Windows 打印消息说找不到 libdir.dll。
所以我的问题是出了什么问题，为什么即使我使用适当的开关，在运行时也不知道 libdir.dll 的路径？
假设我有 prog1 和 prog2，每个都包含它们自己的 libdir.dll 副本，并且它们都开始运行，同时加载库中的代码。内存中发生的情况是加载了两个副本，还是链接器发现存在一个副本并将其用于两个程序？
第二个问题是关于如何加载库（任何操作系统）。链接器总是加载整个库还是只加载所需的部分？例如，如果程序引用库中的函数 foo() ，链接器是否映射到只记忆该函数还是先记忆整个库？
I,m using gcc compiler(MinGW) on Windows XP.I created a .dll library libdir.dll than I tried to build a program that is using that library.
I don't want to put that .dll file into System or System32 folder nor to set path to it in PATH variable, what i want is to give that information to the program itself.
I know there is a -R and -rpath switches available so i was gonna link it with one of them.
First -rpath:
gcc -L/path/to/lib -Wl,-rpath,/path/to/lib main.o -ldir -o progThan -R:
gcc -L/path/to/lib -Wl,-R,/path/to/lib main.o -ldir -o prog
This links successfully into prog but when i start the program Windows prints message that it cannot find libdir.dll.
So my question is what went wrong, why path to libdir.dll is not known in runtime even when I'm using appropriate switches?
Let's say i have prog1 and prog2 each containing their own copy of libdir.dll and both of them start to run at the same time loading code in the library.What happens in memory is there a two copies loaded or linker figures out that there is a copy and uses that for both programs?
Second question is about how libraries are loaded(any OS).Does linkers always load entire library or just parts needed?For example if program references function foo() which is in the library, does linker maps into memory only that function or entire library first?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
这个问题的一部分是这个问题的重复： 是否有与 -rpath 链接器标志等效的 Windows/MSVC？
答案的摘要是 Windows 上没有与 RPATH 直接等效的东西。
由于您排除了将 DLL 放置在默认库搜索路径中（在 Windows 上，该路径包括您列出的系统目录和 PATH 环境变量中的目录），因此您只剩下以下选项：
Part of this question is a duplicate of this one: Is there a Windows/MSVC equivalent to the -rpath linker flag?
The summary of the answer is that there is no direct equivalent of RPATH on Windows.
Since you precluded placing your DLLs in the default library search path (which on Windows includes the system directories you listed and the directories in the PATH environment variable), you are left with these options:
只有两种真正的选择：将 DLL 放在与 EXE 相同的文件夹中，或者将其放在 EXE 的工作目录中。后者并不是一个很好的选择，因为您必须创建一个快捷方式以使默认工作目录不同于包含 EXE 的目录。
仅当您想与其他应用程序共享 DLL 时，不将 DLL 与 EXE 放在同一目录中才有意义。为了避免不可避免的 DLL 地狱，您需要将 DLL 存储在并行缓存中。创建清单并将其嵌入 EXE 所需的工具以及将 DLL 部署到目标计算机所需的安装程序可能很难通过您的工具链获得。无论如何，这种事很少发生。
There are only two real alternatives: put the DLL in the same folder as the EXE or put it in the working directory for the EXE. The latter being not much of an option since you'd have to create a shortcut to make the default working directory different from the directory that contains the EXE.
Not putting the DLL in the same directory as the EXE only makes sense if you want to share the DLL with other applications. To avoid the inevitable DLL hell this causes, you'd need to store the DLL in the side-by-side cache. The tooling you need to create the manifest and embed it in the EXE and the installer you'd need to deploy the DLL to the target machine are probably hard to come by with your tool chain. It is very rarely done anyway.