如何修复 Linux 项目中的共享库 (.so) 之一?

发布于 2024-12-05 03:50:13 字数 69 浏览 2 评论 0原文

我想快速修复项目的 .so 库之一。重新编译 .so 并替换原来的是否安全?或者我必须重建并重新安装整个项目?或者这取决于?

I want to make a quick fix to one of the project's .so libraries. Is it safe to just recompile the .so and replace the original? Or I have to rebuild and reinstall the whole project? Or it depends?

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

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

发布评论

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

评论(5

纵情客 2024-12-12 03:50:13

这取决于。共享库需要与您的可执行文件二进制兼容

例如,

  1. 如果您更改了库内部函数之一的行为,您可能不需要重新编译。
  2. 如果您更改了应用程序已知的结构的大小(例如通过添加成员),则需要重新编译,否则库和应用程序会认为该结构比实际小,并且当库尝试时会崩溃读取应用程序未写入的额外未初始化成员。
  3. 如果更改应用程序中可见的任何函数的类型或参数位置,则确实需要重新编译,因为库将尝试从堆栈中读取比应用程序放入其中的参数更多的参数(C 就是这种情况) ,在C++中参数类型是函数签名的一部分,因此应用程序将拒绝运行,而不是崩溃)。

经验法则(对于生产版本)是,如果您没有意识到自己正在维护二进制兼容性,或者不确定什么是二进制兼容性,则应该重新编译。

It depends. Shared library needs to be binary-compatible with your executable.

For example,

  1. if you changed the behaviour of one of library's internal functions, you probably don't need to recompile.
  2. If you changed the size of a struct (e.g. by adding a member) that's known by the application, you will need to recompile, otherwise the library and the application will think the struct is smaller than it is, and will crash when the library tries to read an extra uninitialized member that the application didn't write to.
  3. If you change the type or the position of arguments of any functions visible from the applications, you do need to recompile, because the library will try to read more arguments off the stack than the application has put on it (this is the case with C, in C++ argument types are the part of function signature, so the app will refuse run, rather than crashing).

The rule of thumb (for production releases) is that, if you are not consciously aware that you are maintaining binary compatibility, or not sure what binary compatibility is, you should recompile.

纵性 2024-12-12 03:50:13

这当然是使用动态库的目的:如果库中的某些内容需要更新,那么您只需更新该库,而使用它的程序不需要更改。如果您要更改的函数的签名没有改变,并且它完成了相同的事情,那么这通常没问题。

当然,总会有一些边缘情况,其中程序依赖于函数的某些未记录的副作用,然后更改该函数的实现可能会更改副作用并破坏程序;但这就是生活。

That's certainly the intent of using dynamic libraries: if something in the library needs updating, then you just update the library, and programs that use it don't need to be changed. If the signature of the function you're changing doesn't change, and it accomplishes the same thing, then this will in general be fine.

There are of course always edge cases where a program depends on some undocumented side-effect of a function, and then changing that function's implementation might change the side-effect and break the program; but c'est la vie.

沫离伤花 2024-12-12 03:50:13

如果您没有更改共享库的ABI,则只需重建并替换该库即可。

If you have not changed the ABI of the shared library, you can just rebuild and replace the library.

萌梦深 2024-12-12 03:50:13

这取决于是。

但是,我假设您拥有构建其他内容的完全相同的源代码和编译器,现在如果您仅在 .cpp 文件中更改某些内容,那就没问题了。

其他事情,例如更改头文件中的接口(共享库和系统其余部分之间)是不好的。

It depends yes.

However, I assume you have the exact same source and compiler that built the other stuff and now if you only change in a .cpp file something, it is fine.

Other things e.g. changing an interface (between the shared lib and the rest of the system) in a header file is not fine.

深海少女心 2024-12-12 03:50:13

如果您不更改库二进制接口,则仅重新编译和重新部署共享库就可以了。

很好的参考:

If you don't change your library binary interface, it's ok to recompile and redeploy only the shared library.

Good references:

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