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)
Change History (12)
comment:1 Changed 5 years ago by kencu (Ken)
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.
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: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)
Attachment: | patch-legacysupport-fsgetpath.diff added |
---|
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: | assigned → closed |
comment:10 Changed 5 years ago by kencu (Ken)
Resolution: | fixed |
---|---|
Status: | closed → reopened |
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.
<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:
Could be ripe for
legacy-support
if so...