除了静态库之外,我还可以使用“gcc -llibnamehere”绑定共享库吗?
Posted
技术标签:
【中文标题】除了静态库之外,我还可以使用“gcc -llibnamehere”绑定共享库吗?【英文标题】:Can I bind shared libraries with "gcc -llibnamehere", in addition to static ones? 【发布时间】:2012-04-30 16:44:56 【问题描述】:两个项目:
加载器,一个独立的可执行文件(只加载模块) 任何模块,一个共享库 (librainbowdash.so)(可以有很多模块)现在,该模块与-lpthreads
链接,但我收到一些奇怪的错误,这让我认为 pthreads 仅绑定为共享对象,并且当加载程序加载模块时 pthreads 没有被加载。 (用GDB调试是不可能的,那种错误)。
我以为-l
开关只允许静态库?可以?不是吗?
【问题讨论】:
它没有。-l
仅用于方便的路径查找。
【参考方案1】:
-l
指定库名称。由链接器将库名称解析为静态库或要链接的共享对象。加载使用的任何共享库是加载器的工作。
【讨论】:
我就是这么想的。有没有办法强制它成为一个静态库?我想.a 版本中有 libpthreads.so 可用.. 取决于链接器。使用 GNU ld,您可以在-l
参数之前使用 -static
。【参考方案2】:
如果您查看 ld 和 gcc 手册页,可以定义“选项组”,我可能有点生疏,但它应该类似于
gcc -o yourprog -Wl,-Bstatic yourprog.c -lstatic_lib -Wl,-Bdynamic -ldynamic_lib
确切的咒语可能是错误的。
根据经验,通过静态库的完整路径已证明比找出上述咒语的确切形式要容易得多。
话虽如此,我怀疑静态链接 pthread 是否会带来很多好处。
我想你也可以使用
gcc -pthread ...
也是。
使用简单的 -static 将使输出及其所有依赖项变为静态。这可能不是你想要的。
【讨论】:
【参考方案3】:您的共享库可能在错误的位置指向lpthread
。使用ldd
工具,例如ldd libfoo.so
通常是查找此类链接问题的一种非常有效的方法。
【讨论】:
以上是关于除了静态库之外,我还可以使用“gcc -llibnamehere”绑定共享库吗?的主要内容,如果未能解决你的问题,请参考以下文章
除了 keycloak 令牌之外,我还需要其他任何东西来访问使用 keycloak 保护的服务吗?