7:33 p.m.
Matt, are you looking to use Ganesha on Mac for production, or are you
using it as a development platform?
I almost had Ganesha compiling on MacOSX a while back, but only to use as a
developer platform: I wanted to be able to code on planes, as I (used to)
fly a lot of 12h+ long haul flights. Then I discovered that Docker
containers are a great way (and it's free!) to run a full Linux environment
on a Mac. Just build your own docker container with developer tools and
dependencies.
On Tue, Sep 1, 2020 at 10:22 AM <matvore(a)comcast.net> wrote:
Thank you for the response.
Fortunately I don't think I need FSAL_VFS. My goal is to create an
in-memory filesystem in order to benchmark macOS's NFS client. I
essentially want to create a more specialized FSAL_MEM. If I understand the
NFS-Ganesha architecture properly, FSAL_VFS is not needed since I don't
care about a concrete POSIX filesystem.
Here are a few things I'm hacking around to get things building, and I
hope to have some results in the next few days:
- The Apple "ld" doesn't support --version-script=, so it must be
switched to use -exported_symbols_list
- The build system assumes the URCU library header files are in the
search path by default, which is not the case with homebrew.
- We must use EPOLL emulation (using kqueue) which was originally written
for FreeBSD
- I changed several #include lines from <gssapi/foo.h> to <GSS/foo.h> to
get around compiler errors though I'm not sure if this actually solved
anything :)
- Redefining of strlcpy and strnlen
- Some atomic_fetch_* functions are not defined properly
_______________________________________________
Devel mailing list -- devel(a)lists.nfs-ganesha.org
To unsubscribe send an email to devel-leave(a)lists.nfs-ganesha.org