[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Exactly why acl doesn't compile on, for example, Mac OS (and how to fix
From: |
Gordon Steemson |
Subject: |
Exactly why acl doesn't compile on, for example, Mac OS (and how to fix it) |
Date: |
Fri, 15 Dec 2023 14:43:32 -0800 |
Hi all,
I discovered that you can't install the acl package on a Mac, because you can't
install the attr package on a Mac. Some digging around turned up the reasons
why:
It turns out there are two showstoppers, with the same root cause -- the Mac OS
kernel has a different set of extended-file-attribute accessors than the Linux
kernel. (I found that the GNUlib project's documentation includes a long list
of other OSes which are in the same situation, together with a note that no one
over there has yet found time to address it. Maybe the fixes I've gotten
together should be deemed related? I don't know how widely their stuff is
actually used.)
Specifically, the Mac OS kernel doesn't have Linux's four distinct syscalls for
accessing symlink attributes, but rather includes a "flags" parameter on all of
the other eight functions; the "don't follow a symlink" flag is among its
possible contents.
Further, because backward-compatibility access to classic Mac OS resource forks
(which could occupy up to 16 MiB) was done by treating them as a type of
extended attribute, the "get" and "set" calls include an additional parameter
for where in the attribute to begin reading or writing. All of this makes for
a much more flexible xattrs implementation, but in consequence it is not
directly compatible.
These issues were pretty simple to work around by rewriting the wrappers in
syscalls.c to act as glue code (with the aid of a local substitute for
<sys/xattr.h>, which on Macs also declares completely different binary values
for the function-call flags than Linux does). However, I have no idea how to
go about framing that as a patch to the attr package, because it involves such
extensive changes. Functionally, it appears to require that syscalls.c contain
conditional compilation directives with totally different versions of the
entire file contents in each of the two conditional branches. What's the
_right_ way to handle that?
Parenthetically, I will also note that the relatively recent patch deleting the
linker script was completely the right thing to do, as (at least on my ancient
machine) the linker is not GNU's and had no idea what to do with it. Because I
naïvely started with the most recent release tarball rather than the current
repository, I found I had to make that edit too.
Anyway. Advice please?
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- Exactly why acl doesn't compile on, for example, Mac OS (and how to fix it),
Gordon Steemson <=