If the libnfs port/package is installed, 'make configure' enables nfs support and 'make build' fails:
In file included from engines/nfs.c:3:
/usr/local/include/nfsc/libnfs.h:1216:23: error: field has incomplete type
struct timeval atime;
- patch to include sys/time.h (and pass upstream). This is actually, now that I look at it closer, maybe more of a libnfs bug.
- explicitly disable nfs support (--disable-libnfs)
- make an NFS option (pass --enable-libnfs and add to LIB_DEPENDS). This port should not be silently dependent on libnfs anyway - there should be an explicit LIB_DEPENDS for libnfs (if desired).
I guess I vote for patching libnfs to include the right file in libnfs.h, and makeing NFS support in fio an OPTION.
See also bug 258376 for a real world example.
(In reply to John Hein from comment #0)
If you want I can create patches for both ports.
P.S. Just found same issue and prepared for report bug upstream, but found this: https://github.com/sahlberg/libnfs/issues/358.
Created attachment 227795 [details]
[patch] add NFS option so dependency on libnfs is explicit
Add NFS option so dependency on libnfs is explicit. Right now, libnfs is detected at configure time. If it is found, fio is linked with libnfs. Since the dependency is not (currently) recorded, libnfs could later be removed, and fio would be left broken (not runnable due to missing lib).
This new option defaults to off which matches how packages were built when no libnfs was installed.
portlint - ok
testport - ok (tested with NFS off and on)
libnfs package is not a dependency, I didn't intend to add it as a dependency yet, I assume you build the package not in poudriere. Anyway I'd like to wait for upstream decision and resolution on that.
(In reply to Kirill Ponomarev from comment #4)
libnfs becomes a dependency if it is installed and the fio 'configure' step detects it. This can occur outside of poudriere certainly, but also inside poudriere if you do a 'bulk' build that includes both libnfs and fio.
I can understand waiting until libnfs is fixed before proceeding - either via the upstream issue #358 or bug 258376. No response yet on either.