searchfs @0.3.0: fatal error: 'sys/fsgetpath.h' file not found

[ryandesign (Ryan Carsten Schmidt)]

​searchfs doesn't build on macOS 10.12 or earlier:

main.m:46:10: fatal error: 'sys/fsgetpath.h' file not found
#include <sys/fsgetpath.h>
         ^
1 error generated.

[kencu (Ken)]

<​https://github.com/st3fan/osx-10.9/blob/master/xnu-2422.1.72/bsd/sys/fsgetpath.h>

<​https://git.saurik.com/apple/xnu.git/history/3903760236c30e3b5ace7a4eefac3a269d68957c?f=bsd/sys/fsgetpath.h>

It may have been around longer, but hidden away:

/*
 * Obtain the full pathname of a file system object by id.
 *
 * This is a private SPI used by the File Manager.
 */
ssize_t fsgetpath(char * __restrict buf, size_t bufsize, fsid_t* fsid, uint64_t objid);

Could be ripe for legacy-support if so...

[kencu (Ken)]

OK, here's some tasty bits from someone who really knows his stuff <​https://forums.developer.apple.com/thread/103162> including this little snippet that looks useful for older systems:

#include <sys/syscall.h>  
#define fsgetpath(buf, bufsize, fsid, objid)  \  
  (ssize_t)syscall(SYS_fsgetpath, buf, (size_t)bufsize, fsid, (uint64_t)objid)  

[kencu (Ken)]

It looks like our software authour actually has included a compatibility function already, almost identical to the one in the apple developer thread I linked to -- however, he assumed the build would be against the 10.13 SDK, and did not test for the availability of the fsgetpath.h header before including it, ergo the error building against an older SDK. I'll write up a patch that can be upstreamed, and that should fix the build on 10.7 to 10.12.

For 10.6 and below, we're stuck because of the use of NSRegularExpression which is 10.7+ only.

[kencu (Ken)]

So it does work, with the enhanced legacy-support-devel port that is currently forked off the main repo:

$ port -v installed searchfs
The following ports are currently installed:
  searchfs @0.3.0_0 (active) platform='darwin 15' archs='x86_64' date='2019-09-29T12:46:23-0700'

and

$ searchfs portconfigure.tcl
/opt/local/libexec/macports/lib/port1.0/portconfigure.tcl
/opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/base/src/port1.0/portconfigure.tcl

but using legacysupport on newer OS versions is bring out some inconsistencies in the definitions of functions and the granularity of the various type definitions that will need to get sorted out before the new legacysupport port can be released to the wild.

[pdvnl]

on one mac i'm running 10.11, where can i get this version?

[ryandesign (Ryan Carsten Schmidt)]

Ken, did the legacysupport issues you mentioned above get sorted out? Can that portgroup be safely applied to this port now?

[kencu (Ken)]

I did not commit it as yet. It looks like we got sidetracked into a complicated patch of ionic's and I set it to the side.

Here's what I had done (attached). It did work, as above, I was just trying to get it just right I guess.

[kencu (Ken)]

I also found this other workaround, that works in a different fashion, that I was considering <​https://github.com/kencu/macports-ports/commit/573f8c1f9dc4fb5cd7fa805538006820385622fd>. This doesn't use legacysupport.

[kencu (Ken)]

In 8b6e6cd11491a01eef16e9eae36be612af695035/macports-ports (master):

searchfs: fix fspatch workaround for older systems

include the header only if it exists
fixes build on older SDKs without the fswatch.h header
don't warn about the implicit function definition

closes: #59124

[kencu (Ken)]

this didn't work right, apologies. The authour has a different method of weak linking than usual in this software, and although this did appear to work for me on one system, I thought, it was not in the end a general solution. I've pushed forward the legacysupport PG approach.

You could also attack this in this port with some suitable #ifdefs but using legacysupport seems like a more general solution.