在我的configure/configure.ac中，我会进行多次PKG_CHECK_MODULES来电。他们中的大多数都返回相同的-I path:-I/usr/local/include，也返回相同的-L path: -L/usr/local/lib.
我会说-I path没有任何区别，因为gcc会及时编译一个来源。当编译多个源时，它可能会有所不同吗？
但是，它可能会对库产生影响，因为以下结构是可能的：
-L / usr / local / lib -lX11 -L / usr / lib -lcurses -L / opt / lib -lcups
我猜每个-L option都会更改当前的顶级库搜索路径。
这一切都正确吗？我应该忽略-I冗余，还是试图折叠路径？如何崩溃？
（PS。请不要对-I，-l中的字母感到困惑：第一个是大写"i"，我要问的包含路径选项）
答案 0 :(得分：0)
每个-L选项实际上只是在当前搜索路径的末尾添加了一些东西，这意味着链接到不同位置的不同库是一个难以产生通用解决方案的问题。如果在两个位置A和B中有相同的两个库，并且您想要来自A的第一个库和来自B的第二个库，那么使用-L选项进行此操作会令人惊讶地烦人。您最终必须在链接行中包含.so文件的完整路径。
换句话说，在：
-L/usr/local/lib -lX11 -L/usr/lib -lcurses -L/opt/lib -lcups
将首先在/usr/local/lib，然后/usr/lib，然后/opt/lib中搜索libcups。如果/usr/local/lib中有一个libcups，你仍然会得错。关于唯一可以确定的方法是将-L/opt/lib -lcups替换为/opt/lib/libcups.so（这不是可移植的;例如，它不适用于HP-UX或AIX）。
要回答您的问题，大多数人都不会费心去清理冗余。这种编译命令行在使用多个库的项目中非常典型。
答案 1 :(得分：0)
您可以修改PKG_CHECK_MODULES以将必要的标记放入LDFLAGS和CPPFLAGS而不是FOO_LIBS和FOO_CFLAGS，并检查pkg-config的结果{1}}是多余的，如果已经存在则不添加它们。在这样做时，最好添加AC_CHECK_LIB的一些调用来验证pkg-config返回的信息。这样做的另一个好处是可以大幅清理所有Makefile.am，因为他们不再需要明确引用@FOO_LIBS@和@FOO_CFLAGS@。但是，停止使用PKG_CHECK_MODULES可能更容易。 （见PKG_CHECK_MODULES considered harmful?）