我正在创建一个实用程序,取决于libassuan
撇开其他依赖。虽然这些'其他'提供共享库,但libassuan
只有静态的。便携式方式静态链接到其中一个库
libassuan
都配备了简单libassuan-config
工具,它旨在为编译器/连接器使用提供CFLAGS
& LDFLAGS
。这些LDFLAGS
将该库称为-lassuan
。
化妆的标准调用的结果则是:
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优先选择静态库而不是缩进的shared。我见过的解决方案建议使用类似的东西:
-Wl,-Bstatic -lassuan -Wl,-Bdynamic
但我不认为这将是一个便携式。
我认为最好的解决方案是提供静态库文件的完整路径,但libassuan-config
没有提供太多的帮助(我可以从中得到的是-L/usr/lib64 -lassuan
)。
也许我应该尝试通过“解析”来创建静态库的路径返回LDFLAGS
和使用-L
目录名和-l
的库名 - 然后希望在所有情况下libassuan-config
将返回它这样。
您对此有何看法?有没有好的,简单的便携式解决方案来解决这个问题?
PS。请注意,虽然我在这里指的是gcc,但我想使用能够与其他编译器一起工作的东西。
PS2。还有一个问题:如果包只安装静态库,返回LDFLAGS
而不是完整的.la
路径可以被认为是一个错误?
非常感谢你,将'LDFLAGS'移动到命令行结束后,一切正常。虽然'libassuan-config'没有像pkg-config一样提供拆分'LDFLAGS'&'LIBS'。 – 2009-09-03 18:23:18