将静态编译的 exe 与共享内存的库的不同版本混合在一起
对于这个冗长的问题，我提前表示歉意，但我想确保我没有遗漏任何可能改变您的回答的关键点。
我负责维护用“C”编写的系统软件其中我们有一些常见的“.a”库。我们有一个我称之为“执行管理器”的人，其主要工作是分叉并执行“测试作业”可执行文件的变量列表，并在测试作业进程终止后将控制权返回给执行管理器。所有可执行文件（包括执行管理器）都静态链接到上述库。执行管理器及其派生的测试作业进程通过共享内存使用 IPC。通用库之一包含包装函数，用于使用永不更改的预定义密钥创建和附加共享内存。
几个月前，我们锁定了我们的软件（测试作业加上执行管理器），静态编译它们并发布它们以对测试作业进行“验证”。从那时起，出现了一些对执行管理器进行更改的请求，这将需要对选定的几个常见库函数进行更改。然而，管理层决定他们不想针对新版本的公共库重新编译测试作业，因为这将要求他们重新验证他们当前拥有的测试作业可执行文件；他们不想花钱这样做。
由于所有可执行文件都是静态编译的，因此我通常会说，将执行管理器与针对同一公共库的不同版本静态编译的测试作业混合不会出现问题。然而，通过共享内存包含 IPC 让我想知道这是否仍然正确。我的直觉告诉我，只要共享内存包装函数（尤其是密钥）没有发生任何变化，那么我们应该没问题，但我真的可以在这方面使用一些专家的意见。
感谢您花时间阅读本文，非常感谢。
I apologize in advance for the long-winded question but I wanted to make sure I didn't leave out any key points that may alter your response.
I am responsible for maintaining system software written in 'C' of which we have a few common '.a' libraries. We have what I would call an "Execution Manager" who's main job is to fork and and exec a variable list of "test-job" executables and return control back to the Execution Manager once the test-job process terminates. All executables, including the execution manager, are statically linked against the aforementioned libraries. The execution manager and the test-job processes it forks use IPC via shared memory. One of the common libraries contains wrapper functions to create and attach the shared memory with a predefined key that never changes.
A few months ago we locked down our software (test-jobs plus execution manager), compiled them statically and released them to have the test-jobs "proofed". Since that time, there have been some requests for changes to be made to the execution manager which would require changes to a select few common library functions. However, management has decided that they do not want to recompile the test-jobs against the new version of the common libraries because that will require them to re-proof the test-job executables they currently have; and they do not want to expend the money to do that.
Since all executables were statically compiled, I would normally say mixing an Execution Manager with test-jobs statically compiled against different versions of the same common library would not be a problem. However, the inclusion of IPC via shared memory is making me wonder if that is still true. My gut says that as long as there were no changes to the shared memory wrapper functions, especially the key, then we should be OK, but I could really use some expert opinions on this.
Thanks for taking the time to read this, much appreciated.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
只要定义进程如何通过共享内存相互通信的数据结构和协议没有改变，就应该没问题。 （也就是说，存在于两个进程之间的小 ABI）。
You should be OK, as long as the data structures and protocols that define how the processes talk to each other over the shared memory have not changed. (That is, your little ABI that exists between the two processes).
我想确认 caf 所说的内容。您已经正确识别了关键位：用于访问共享内存的密钥和包装函数。这些位并不关心它们是否在 .o 文件中定义、是否是 .a 文件的一部分，或者它们在 .a 文件中的位置。在链接时，它们被拉入 exe，保留其原始功能；它们在 .a 文件中的“临时位置”不会影响它们如何找到共享内存段、如何确定相关偏移量等。因此，如果这些（即键和包装函数）没有改变，您应设置。
I'd like to confirm what caf says. You have correctly identified the crucial bits: the key and the wrapper functions used to access the shared memory. These bits don't care whether they're defined in a .o file, whether they're part of a .a file, or where they are within a .a file. At link time, they get pulled into the exe, keeping their original functionality; their "temporary home" in a .a file doesn't affect how they find the shared memory segment, how they determine the relevant offsets, etc. So if these (i.e., the key and the wrapper functions) haven't changed, you should be set.