4

I have a library that I originally developed for Linux. I am now in the process of porting it to Cygwin. I have noticed that every library on my Cygwin system is installed like this:

  • DLL (cygfoo.dll) installed to /usr/bin mode 755
  • Static archive (libfoo.a) installed to /usr/lib mode 644
  • Import library (libfoo.dll.a) installed to /usr/lib mode 755

The first two make perfect sense to me. DLLs are executables so they should be mode 755. Static archives are not executables, so they are mode 644. The third one, however, seems odd to me. Import libraries are in fact static archives, not executables (ar -t libfoo.dll.a lists the contents of the archive). Shouldn't they also be installed mode 644?

Why is it the convention on Cygwin to install import libraries with mode 755?

Dan Moulding
  • 211,373
  • 23
  • 97
  • 98
  • 1
    @Wooble: That's because `.dylib`s and `.so`s *are* executables. Archives aren't. – Dan Moulding Jun 20 '12 at 13:43
  • You could try to chmod one of the key dll.a files to 644 to see where it will break, if it breaks. – tomdemuyt Jun 28 '12 at 20:44
  • @DanMoulding, `library` was nuked as part of the 2012 tag cleanup. Please don't recreate it. – Charles Oct 26 '12 at 03:12
  • @Charles: And I vehemently opposed that deletion. It wasn't a community decision, but forced down on us without good reasoning behind it (of course, no one will ever know about this because all the evidence has been destroyed by the perpetrators of this callous killing of an innocent tag). Please stop deleting it. It's kinda laughable that programmers can't come to SO to ask, learn, and teach about libraries as a primary subject. There's plenty to ask, learn, and teach about, like: design, implementation, **installation**. – Dan Moulding Oct 26 '12 at 10:58
  • @DanMoulding, unfortunately the tag was abused, and I fully support keeping it dead. It *wasn't* used to talk about design and implementation, but "I need a library for X" or "I'm using the X library" where X is another tag. In the common use, it added *nothing* to the question. The things you mentioned are totally on-topic, but using a tag called "library" to classify related questions is going to backfire again when it continues to be abused by uninformed users. – Charles Oct 26 '12 at 17:01
  • @DanMoulding, this should probably move to meta, but I'd like to point out [this](http://stackoverflow.com/q/13083000/168868) [morning's](http://stackoverflow.com/q/13083671/168868) [examples](http://stackoverflow.com/q/13085275/168868) of [bad](http://stackoverflow.com/q/13085529/168868) use, and the [only good use](http://stackoverflow.com/q/13088365/168868). The tag is a tarpit for people that don't know how to tag. Let's keep it dead. If you want help coming up with a better way to classify *good* "library" questions, please head over to Meta and we can continue the discussion there. – Charles Oct 26 '12 at 17:06

4 Answers4

0

The only answer that occurs to me is that the installer is looking for the ".dll" string in the filename to activate the executable attribute (x) of the copied files... should been looking for /.+\.dll$/ (.dll only at the end).

It is understandable that the impedance mismatch between OS's/filesystems force the installer/copier to have a strategy to decide attribute values at the installer operation (it is easier than have to map a attribute list to the copied file... and in windows only have to look for .exe, .com and .dll)

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

ZEE
  • 2,931
  • 5
  • 35
  • 47
0

Back to 2000:

On NTFS partitions, NT/W2K require the execute permission for DLLs to allow loading a DLL on process startup.

That's no problem unless a person using ntsec gets a tar archive packed by a person not using ntsec or packing on a FAT partition. Since Cygwin fakes the execute permission only for the suffixes "exe", "bat", "com", DLLs are treated as non executable by the stat() call when ntsec isn't set.

When a person using ntsec unpacks that tar archive, the start of an application which requires one of the DLLs from the archive will fail with the Windows message

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

which isn't that meaningful for most of the users.

To solve that problem we would have to do a simple step. Fake execute permissions for DLLs when ntsec isn't set or the file system doesn't support ACLs (FAT/FAT32).

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

hasanyasin
  • 6,222
  • 1
  • 17
  • 16
-1

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

Remove permission to execute the file, and Windows won't let any of the code inside it be executed, even if the process doing the executing is separate.

Side note: it's a common misconception that there's no +x bit for Windows. That's technically true; Windows doesn't use POSIX rwx permissions, although Cygwin does try to provide an interface that resembles them. Windows does use ACLs (Access Control Lists) for permissions, however, and these do have a concept of "execute permissions", which is what Cygwin maps down to its +x bit.

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

me_and
  • 15,158
  • 7
  • 59
  • 96
  • That makes perfect sense for the DLLs in `/usr/bin`. But I'm not asking about the DLLs. I'm asking about the import libraries (`*.dll.a`, equivalent to MSVC `*.lib`) that get installed to `/usr/lib`. I'll clarify the question. – Dan Moulding Jun 21 '12 at 10:25
-1

Seems it's just a lazy hack resulting in this behavior for filenames containing ".dll". See hasanyasin's answer for the reasoning behind the "fix" (here).

MattBianco
  • 1,501
  • 2
  • 20
  • 30