我有一个最初为 Linux 开发的库。我现在正在将其移植到 Cygwin。我注意到我的 Cygwin 系统上的每个库都是这样安装的：
cygfoo.dll) 安装到/usr/bin模式 755libfoo.a) 安装到/usr/lib模式 644libfoo.dll.a) 安装到/usr/lib模式 755前两个对我来说很有意义。DLL 是可执行文件，所以它们应该是模式 755。静态存档不是可执行文件，所以它们是模式 644。然而，第三个对我来说似乎很奇怪。导入库实际上是静态档案，而不是可执行文件（ar -t libfoo.dll.a列出档案的内容）。他们不应该也安装模式644吗？
为什么 Cygwin 的约定是安装模式为 755 的导入库？
回到 2000 年：
在 NTFS 分区上，NT/W2K 需要 DLL 的执行权限才能允许在进程启动时加载 DLL。
这没有问题，除非使用的人
ntsec获得了由不使用ntsec或打包在 FAT 分区上的人打包的 tar 存档。ntsec由于 Cygwin 仅伪造后缀“exe”、“bat”、“com”的执行权限，因此当未设置stat() 调用时，DLL 将被视为不可执行。当使用该 tar 存档的人
ntsec解压该 tar 存档时，需要存档中的一个 DLL 的应用程序的启动将失败并显示 Windows 消息“应用程序未能正确初始化（0xc0000022）”
这对大多数用户来说意义不大。
为了解决这个问题，我们必须做一个简单的步骤。
ntsec未设置 DLL 或文件系统不支持 ACL (FAT/FAT32)时的虚假执行权限。
这里：http ://cygwin.com/ml/cygwin-developers/2000-10/msg00044.html
我唯一想到的答案是安装程序正在文件名中寻找“.dll”字符串来激活复制文件的可执行属性（x）......应该寻找 /.+\.dll$/ （.dll 仅在最后）。
可以理解的是，操作系统/文件系统之间的阻抗不匹配迫使安装程序/复制程序在安装程序操作时有一个决定属性值的策略（这比必须将属性列表映射到复制的文件更容易......并且仅在 Windows 中）必须寻找 .exe、.com 和 .dll）
要确认这一点，请将您的“libfoo.dll.a”重命名为“libfoo.dxx.a”并对其进行测试...
这是 Windows 要求：由于 .dll 文件包含将要执行的代码，因此需要设置可执行位。
删除执行文件的权限，Windows 不会让其中的任何代码被执行，即使执行执行的进程是分开的。
旁注：Windows 没有 +x 位是一个常见的误解。这在技术上是正确的；Windows 不使用 POSIX rwx 权限，尽管 Cygwin 确实尝试提供类似于它们的界面。但是，Windows 确实使用 ACL（访问控制列表）来获取权限，并且这些确实具有“执行权限”的概念，这就是 Cygwin 映射到其 +x 位的内容。
如果您想要资源/进一步阅读，Cygwin 邮件列表上对此进行了长时间的讨论。
似乎这只是一个懒惰的黑客行为，导致包含“.dll”的文件名出现这种行为。有关“修复”背后的原因，请参阅 hasanyasin 的回答（此处）。