我想在 Linux 中对我的可执行文件中的库路径进行硬编码。在 OS X 上，这是通过在构建库时在 -o 参数之后提供完整路径来实现的。例如，我在 OS X 上构建了一个这样的库：
cc foo.c --shared -o /home/sander/libfoo.so
当我构建一个与该库链接的名为“bar”的可执行文件时，我在该可执行文件上使用 otool -L 时，我得到以下输出：
bar:
/home/sander/libfoo.so (compatibility version 0.0.0, current version 0.0.0)
我现在可以从任何地方运行这个可执行文件，它总是能够找到库。
我正在使用 gcc 在 Linux 上寻找等效的功能。我宁愿不使用 rpath，因为它没有链接到特定的库 + 路径。
我试过使用带有 GCC 的预编译头文件来加速我的构建之一。这是一个包含大约 80 个文件的项目，其中大部分包含一个我预编译的头文件。这个头包括大量的其他头。至少在纸面上，这似乎是使用 PCH 的一个很好的用例。
使用 clang 时，我得到了预期的加速，大约快了 2 倍。然而，在 gcc 上，编译需要更长的时间。
我将我的 PCH 存储在一个单独的目录中，并尝试使用 来添加目录-I，以及直接指定 PCH -include（这不起作用：gcc 最终包括 PCH 和普通标头）。PCH 使用与源文件相同的选项进行编译。
没有 PCH 编译需要大约 13 秒。使用 PCH 大约需要 18 秒。我验证与-H和-Winvalid-pch该GCC（仅）包括预编译的头。-H单个文件的完整输出如下所示：
! .bake_cache/x64-Linux-debug/include/corto.h.gch
./src/lang/boolean.c
本!应表明，GCC成功加载PCH：
-H 打印使用的每个头文件的名称，以及其他正常活动。每个名称都缩进以显示它在“#include”堆栈中的深度。预编译的头文件也会被打印出来，即使它们被发现是无效的；一个无效的预编译头文件用 '...x' 打印，一个有效的用 '...!' 打印 .
来自：https : //gcc.gnu.org/onlinedocs/gcc/Preprocessor-Options.html
我不知所措。gcc 似乎能够定位和使用 PCH，但仍然需要更长的时间。知道是什么原因造成的吗？