我正在创建一个依赖于libassuan其他依赖的实用程序。虽然这些“其他人”提供了共享库，但libassuan仅提供静态库。
libassuan附带简单的libassuan-config工具，旨在提供CFLAGS＆amp; LDFLAGS供编译器/链接器使用。这些LDFLAGS将库称为-lassuan。
标准调用make的结果是：
cc -I/usr/include/libmirage -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -lmirage -lglib-2.0 -L/usr/lib64 -lassuan -o mirage2iso mirage2iso.c mirage-getopt.o mirage-wrapper.o mirage-password.o mirage-password.o: In function `mirage_input_password': mirage-password.c:(.text+0x1f): undefined reference to `assuan_pipe_connect' mirage-password.c:(.text+0x32): undefined reference to `assuan_strerror' collect2: ld returned 1 exit status make: *** [mirage2iso] Error 1
（我刚刚开始编写这个单元，这就是没有更多错误的原因）
因此，如果我理解正确的结果，gcc不希望将应用链接到libassuan.a。
在这里使用-static将导致gcc更喜欢静态库而不是共享的。我已经看到解决方案建议使用类似的东西：
-Wl,-Bstatic -lassuan -Wl,-Bdynamic
但我不认为它是便携式的。
我认为最好的解决方案是提供静态库文件的完整路径，但libassuan-config没有提供太多帮助（我可以从中获得-L/usr/lib64 -lassuan）。
也许我应该尝试通过'解析'返回LDFLAGS并使用-L作为目录名称并使用-l作为库名称来创建静态库路径 - 然后希望在所有情况下libassuan-config都会像那样返回它。
你怎么看？有没有好的，简单的便携式解决方案来解决这个问题？
PS。请注意，虽然我在这里指的是gcc，但我想使用一些可以与其他编译器一起使用的东西。
PS2。另外一个问题：如果包只安装静态库，那么返回这样的LDFLAGS而不是完整的.la路径可以被视为一个错误吗？
答案 0 :(得分：1)
链接时，可能是在静态库中查找订单符号。订单很重要。 ） 假设gcc可以找到libassuan.a并且它实际上提供了链接器抱怨的功能，请尝试：
cc -I / usr / include / libmirage -I / usr / include / glib-2.0 -I / usr / lib64 / glib-2.0 / include -lmirage -lglib-2.0 -L / usr / lib64 -o mirage2iso mirage2iso .c mirage-getopt.o mirage-wrapper.o mirage-password.o -lassuan
既然你说libassuan在/ usr / lib64下它可能是一个64位的库，你的应用程序和其他库也是64位吗？
答案 1 :(得分：1)
编译器的命令行选项不是便携式的。它没有标准。每个编译器都使用它自己的，而且几个编译器只能非正式地同意以命令行格式相互遵守。最便携的链接方式当然是使用libassuan-config。我认为，它不仅可以生成gcc的标志，还可以生成其他编译器。如果它不能，那么我认为没有可移植的方式（除了CMake或更高级别的东西）。
您显示的cc命令行完全正确。如果你有一个静态库libassuan.la并且它的路径被提供给-L选项，那么编译器会链接它。你可以从它的输出中看到它：如果没有找到静态库，它会抱怨像“找不到-lassuan”这样的错误信息。我
此外，如果找不到libassuan.so，那么即使您没有使用-Wl,-Bstatic内容或-static标记，编译器也会静态链接到您的库。
您的问题可能是系统中多个版本的libassuan持续存在。除此之外，我没有看到你提供的任何错误。
答案 2 :(得分：0)
中的libassuan.a目录
我认为第一个错误不是gcc不想将应用程序链接到libassuan.a它更gcc不知道libassuan.a在哪里。你需要传递gcc a -L参数，给出libassuan.a的路径。 例如 -L / home / path