我认为Linux的一个主要设计缺陷是共享对象地狱，它涉及以二进制形式而不是源代码形式分发程序.

I think a major design flaw in Linux is the shared object hell when it comes to distributing programs in binary instead of source code form.

就系统的创建者而言，这不是设计缺陷；这是一个优势-鼓励您以源代码形式分发程序.哦，您想出售您的软件?抱歉，这不是针对Linux优化的用例.

This isn't a design flaw as far as creators of the system are concerned; it's an advantage -- it encourages you to distribute programs in source form. Oh, you wanted to sell your software? Sorry, that's not the use case Linux is optimized for.

库命名约定:共享对象通常不只是简单地称为"libXcursor.so"，而是具有某种版本的扩展名，例如"libXcursor.so.1"，甚至是诸如"libXcursor.so.0.2000"之类的真正有趣的东西. /p>

Library naming conventions: Shared objects often aren't simply called "libXcursor.so" but have some kind of version extension like "libXcursor.so.1" or even really funny things like "libXcursor.so.0.2000".

是的，这称为外部库版本控制.在此处进行阅读.从该说明中应该可以清楚地看到，如果您在通常会给您libXcursor.so.1作为运行时引用的系统上使用标头编译二进制文件，则您兼容的 only 共享库为，尝试dlopen libXcursor.so.0.2000会导致无法预测的崩溃.

Yes, this is called external library versioning. Read about it here. As should be clear from that description, if you compiled your binaries using headers on a system that would normally give you libXcursor.so.1 as a runtime reference, then the only shared library you are compatible with is libXcursor.so.1, and trying to dlopen libXcursor.so.0.2000 will lead to unpredictable crashes.

任何提供libXcursor.so但不提供libXcursor.so.1的系统都是损坏的安装，或者与您的二进制文件也不兼容.

Any system that provides libXcursor.so but not libXcursor.so.1 is either a broken installation, or is also incompatible with your binaries.

库搜索路径:毕竟我应该在哪里寻找* .so文件?

Library search paths: Where should I look for the *.so files after all?

您不应尝试使用它们的完整路径来dlopen这些库中的任何一个.只需调用dlopen("libXcursor.so.1", RTLD_GLOBAL);，运行时加载程序便会在适合系统的位置中搜索该库.

You shouldn't be trying to dlopen any of these libraries using their full path. Just call dlopen("libXcursor.so.1", RTLD_GLOBAL);, and the runtime loader will search for the library in system-appropriate locations.