acl-devel
[Top][All Lists]
Advanced

[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?


reply via email to

[Prev in Thread] Current Thread [Next in Thread]