与Microsoft相比，如何处理Linux CRunTime库

我对Microsoft的CRT有很多概念问题。 对于任何项目，您必须编译所有必需的库以链接到相同版本的 CRT。

第一个问题是当您的项目静态链接到 CRT （/MT） 时。 然后，所有依赖库也必须静态链接自己的 CRT。 所以每个库都有自己的版本 - 例如 - malloc（）。 如果您去年在系统 A 上编译了其中一个库，则该 CRT 版本可能与您当前在另一个系统 B 上使用的服务包 3+ 版本不同。 因此，如果要释放库分配的对象，则可能会遇到问题。

因此，动态链接的CRT似乎是要走的路（/MD）。 使用 dll，所有库都将在系统上获得 CRT 的当前实现。 除了Microsoft的并排机制，情况并非如此。 相反，你将获得标记在编译的库上的 CRT 版本，并将该版本的 DLL 提供给该库。 因此，可能会出现我之前描述的完全相同的问题。 一年前，您针对一个 CRT 在系统 A 上编译了一个库。 一年后，有一个新版本升级。 您的主程序获取具有一个版本的 CRT 的 DLL，库使用另一个版本的 CRT 获取 DLL，可能会出现相同的问题。

那你怎么办？ 我意识到跨库内存分配是不受欢迎的。 但是你可以忽略malloc的例子，想出另一个例子。 您是否让每个开发人员重新编译其计算机上的每个依赖库，以确保所有内容都使用相同的 CRT？ 然后对于版本，您再次重新编译每个库？

这在 Linux 上是如何工作的？ 这是我的主要兴趣。 是否有 GCC 随附的 CRT 或 Linux 系统本身附带 CRT 库？ 我从未见过在Makefils中明确链接的CRT。

在 Linux 上，动态库链接到什么 CRT？ 机器上最新的一个，还是更"并排"的机制。