构建具有依赖项的 Linux 共享库时跳过编译时符号解析

发布于 2024-08-23 17:34:38 字数 160 浏览 8 评论 0原文

在构建共享库(依赖于其他共享库)时,是否有 gcc 标志来跳过编译时链接器对符号的解析?由于某种原因,当我尝试构建依赖于 B.so 和 A.so 的共享库 C 时,即使指定并存在依赖项,我的工具链也会给出 未定义的引用 错误。我听说有一个 gcc 标志可以将依赖解析延迟到运行时。

Is there a gcc flag to skip resolution of symbols by the compile-time linker when building a shared library (that depends on other shared libraries)? For some reason my toolchain is giving undefined reference errors when I try to build shared library C that depends on B.so and A.so, even though the dependencies are specified and exist. I heard there existed a gcc flag to delay the dependency resolution to runtime.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

旧时光的容颜 2024-08-30 17:34:38

我认为您正在寻找 --allow-shlib-undefined。从 ld 手册页

--allow-shlib-undefined
--no-allow-shlib-undefined
    Allows (the default) or disallows undefined symbols in shared libraries. 
    This switch is similar to --no-undefined except that it determines the 
    behaviour when the undefined symbols are in a shared library rather than 
    a regular object file. It does not affect how undefined symbols in regular
    object files are handled.

    The reason that --allow-shlib-undefined is the default is that the shared
    library being specified at link time may not be the same as the one that 
    is available at load time, so the symbols might actually be resolvable at 
    load time. Plus there are some systems, (eg BeOS) where undefined symbols 
    in shared libraries is normal. (The kernel patches them at load time to 
    select which function is most appropriate for the current architecture. 
    This is used for example to dynamically select an appropriate memset 
    function). Apparently it is also normal for HPPA shared libraries to have
    undefined symbols.

允许未定义的符号是不过,默认情况下,所以我猜你的问题实际上是不同的。

I think you're looking for --allow-shlib-undefined. From the ld man page:

--allow-shlib-undefined
--no-allow-shlib-undefined
    Allows (the default) or disallows undefined symbols in shared libraries. 
    This switch is similar to --no-undefined except that it determines the 
    behaviour when the undefined symbols are in a shared library rather than 
    a regular object file. It does not affect how undefined symbols in regular
    object files are handled.

    The reason that --allow-shlib-undefined is the default is that the shared
    library being specified at link time may not be the same as the one that 
    is available at load time, so the symbols might actually be resolvable at 
    load time. Plus there are some systems, (eg BeOS) where undefined symbols 
    in shared libraries is normal. (The kernel patches them at load time to 
    select which function is most appropriate for the current architecture. 
    This is used for example to dynamically select an appropriate memset 
    function). Apparently it is also normal for HPPA shared libraries to have
    undefined symbols.

Allowing undefined symbols is the default, though, so I'm guessing your problem is actually something different.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文