Hi! I'm currently starting to try out notmuch-0.16 on NetBSD. It went off to a rocky start, since it segfaulted in the initial config setup. Debugging it I found that notmuch uses a glibc extension to realpath, allowing NULL as second argument. I've converted it to use a prepared buffer instead; attached is a possible patch that makes notmuch complete its setup phase for me, and adds inclusion of the header files suggested by the realpath man page on NetBSD. Please address this issue in some way in the next release. Additionally, when compiling with clang, there are issues with the visibility. The symptoms are: In file included from lib/database.cc:21: In file included from ./lib/database-private.h:33: ./lib/notmuch-private.h:479:8: error: visibility does not match previous declaration array subscriptstruct visible _notmuch_string_list { ^ ./lib/notmuch-private.h:67:33: note: expanded from macro 'visible' # define visible __attribute__((visibility("default"))) ^ ./lib/notmuch-private.h:52:13: note: previous attribute is here #pragma GCC visibility push(hidden) ^ In file included from lib/parse-time-vrp.cc:23: In file included from ./lib/database-private.h:33: ./lib/notmuch-private.h:479:8: error: visibility does not match previous declaration struct visible _notmuch_string_list { ^ ./lib/notmuch-private.h:67:33: note: expanded from macro 'visible' # define visible __attribute__((visibility("default"))) ^ ./lib/notmuch-private.h:52:13: note: previous attribute is here #pragma GCC visibility push(hidden) ^ 1 warning generated. In file included from lib/directory.cc:21: ./lib/notmuch-private.h:479:8: error: visibility does not match previous declaration struct visible _notmuch_string_list { ^ ./lib/notmuch-private.h:67:33: note: expanded from macro 'visible' # define visible __attribute__((visibility("default"))) ^ ./lib/notmuch-private.h:52:13: note: previous attribute is here #pragma GCC visibility push(hidden) ^ and so on. I guess it is because the visibility differs between c and c++. I've disabled visibility locally, see second attached patch, but of course that's not a solution, just a workaround. Suggestions welcome. Thanks, Thomas