Opened 5 years ago

Last modified 5 years ago

#59124 reopened defect

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

Reported by: ryandesign (Ryan Carsten Schmidt) Owned by: srirangav (Sriranga Veeraraghavan)
Priority: Normal Milestone:
Component: ports Version: 2.6.0
Keywords: Cc: kencu (Ken)
Port: searchfs

Description

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.

Attachments (1)

patch-legacysupport-fsgetpath.diff (6.2 KB) - added by kencu (Ken) 5 years ago.

Download all attachments as: .zip

Change History (12)

comment:1 Changed 5 years ago by 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...

comment:2 Changed 5 years ago by 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)  

comment:3 Changed 5 years ago by 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.

Last edited 5 years ago by kencu (Ken) (previous) (diff)

comment:4 Changed 5 years ago by 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.

comment:5 Changed 5 years ago by pdvnl

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

comment:6 Changed 5 years ago by ryandesign (Ryan Carsten Schmidt)

Cc: kencu added

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

comment:7 Changed 5 years ago by 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.

Changed 5 years ago by kencu (Ken)

comment:8 Changed 5 years ago by 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.

comment:9 Changed 5 years ago by kencu (Ken)

Resolution: fixed
Status: assignedclosed

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

comment:10 Changed 5 years ago by kencu (Ken)

Resolution: fixed
Status: closedreopened

comment:11 Changed 5 years ago by 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.

Note: See TracTickets for help on using tickets.