Why are Cygwin import libraries installed with 755 mode?

I have a library that I originally developed for Linux. I am transferring it to Cygwin now. I noticed that every library in my Cygwin system is installed as follows:

  • DLL ( cygfoo.dll ) installed in the /usr/bin 755 mode
  • The static archive ( libfoo.a ) is set to /usr/lib 644 mode
  • Import library ( libfoo.dll.a ) installed in /usr/lib 755 mode
The first two make perfect sense to me. DLLs are executable files, therefore they must be in 755 mode. Static archives are not executable files, therefore they are 644 mode. The third, however, seems strange to me. Import libraries are actually static archives, not executable files ( ar -t libfoo.dll.a lists the contents of the archive). Shouldn't they be installed in 644 mode?

Why is this agreement on Cygwin to install import libraries in 755 mode?

+4
source share
4 answers

The only answer that arises for me is that the installer looks for the string ".dll" in the file name to activate the executable attribute (x) of the copied files ... should look for /.+ \. dll $ / (. dll only at the end).

It is clear that the impedance mismatch between OS / file systems forces the installer / copier to have a strategy for determining attribute values ​​in the installer operation (easier than comparing the list of attributes with the copied file ... and in the windows you need to search only .exe, .com and .dll )

To confirm this, rename your "libfoo.dll.a" to "libfoo.dxx.a" and test it ...

0
source

Back to 2000:

In NTFS partitions, NT / W2K requires execution permission for the DLL to allow the DLL to load when the process starts.

This is not a problem if only a person using ntsec receives a tar archive packaged by a person who does not use ntsec or packaged on a FAT partition. Since Cygwin falsifies execution permission only for the suffixes "exe", "bat", "com", DLLs are treated as non-executable by calling stat () when ntsec not installed.

When a user using ntsec decompresses this tarball, an application starts that requires one of the DLLs from the archive to fail with a Windows message

"The application failed to initialize correctly (0xc0000022)"

which is not very important for most users.

To solve this problem, we need to take a simple step. False permissions for DLLs when ntsec not installed or the file system does not support ACL (FAT / FAT32).

Here: http://cygwin.com/ml/cygwin-developers/2000-10/msg00044.html

0
source

This is a requirement of Windows: since the .dll file contains the code that will be run, it needs to set the executable bit.

Remove the permission to execute the file, and Windows will not allow any of the code to execute inside it, even if the process executing the execution is separate.

Side note: this is a common misconception that there is no bit + x for Windows. This is technically true; Windows does not use POSIX rwx permissions, although Cygwin is trying to provide an interface similar to them. However, Windows uses access control lists (ACLs) for permissions, and they have the concept of "execute permissions", which means that Cygwin matches its + x bit.

There's a long discussion on the Cygwin mailing list about this if you want sources / further reading.

-1
source

This seems to be just a lazy hack leading to this behavior for filenames containing ".dll". See Hasanyasin's answer to the β€œfix” arguments ( here ).

-1
source

All Articles