Re: notmuch-0.24.1: missing header include
On Sat, May 13, 2017 at 07:54:39PM -0300, David Bremner wrote: > > On Solaris, notmuch-0.24.1 does not compile because lib/message.cc > > uses index(3) but does not include strings.h. > > > > Please apply the attached patch or a similar one. > > > > Thanks, > > Thomas > > In master we've replaced index(3) with strchr(3). Does that fix your > issue, or is the include still needed? Since you already include that's fine. Thanks, Thomas ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
notmuch-0.24.1: missing header include
Hi! On Solaris, notmuch-0.24.1 does not compile because lib/message.cc uses index(3) but does not include strings.h. Please apply the attached patch or a similar one. Thanks, Thomas $NetBSD: patch-lib_notmuch-private.h,v 1.1 2017/04/20 09:06:34 jperkin Exp $ Include strings.h for index(3). --- lib/notmuch-private.h.orig 2017-04-01 12:29:38.0 + +++ lib/notmuch-private.h @@ -38,6 +38,7 @@ NOTMUCH_BEGIN_DECLS #include #include #include +#include #include #include #include ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: notmuch-0.18 issues [was Re: notmuch-0.16: realpath() compatibility issue; clang visibility problem]
On Sun, Mar 12, 2017 at 07:24:53PM +0200, Tomi Ollila wrote: > On Sun, Mar 12 2017, David Bremner wrote: > > > Thomas Klausner writes: > > > >> > >> 1. pkgsrc's copy of rst2man is called "rst2man.py". The configure test > >> > > > > Since I see notmuch in pkgsrc for netbsd, I guess things have improved. > > I had a quick look at the pkgsrc patches [1]. I don't think we're > > interested in carrying the zlib workarounds upstream, but I guess we > > Note that notmuch dump/restore may not work correctly with zlib 1.2.3 ! > I tried a while ago (someone suggested on this mailing list) and got > corrupted data. If newer netbsd has newer zlib I'd suggest to use that. pkgsrc provides a newer zlib. I've removed the compat patches and depend on zlib-1.2.5.2 now, like notmuch's configure requests. Thanks for looking at the pkgsrc patches! Thomas ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
notmuch-0.18 issues [was Re: notmuch-0.16: realpath() compatibility issue; clang visibility problem]
Hi David! Thanks for getting back to me about this. Currently configure (with some patches) says: Checking for Xapian development files... Yes (1.2.17). Checking for Xapian compaction support... Yes. Checking for GMime development files... Yes (gmime-2.4 ). Checking for Glib development files (>= 2.22)... Yes. Checking for zlib (>= 1.2.5.2)... Yes. Checking for talloc development files... Yes. Checking for valgrind development files... No (but that's fine). Checking for bash-completion (>= 1.90)... No (will not install bash completion). Checking if emacs is available... emacs: not found No (so will not byte-compile emacs code) Checking if sphinx is available and supports nroff output... python: not found No (falling back to rst2man). Checking if rst2man is available... Yes. Checking which platform we are on... Unknown. *** Warning: Unknown platform. Notmuch might or might not build correctly. Checking byte order... 1234 Checking for canonicalize_file_name... No (will use our own instead). Checking for getline... Yes. Checking for strcasestr... Yes. Checking for strsep... Yes. Checking for timegm... Yes. Checking for dirent.d_type... Yes. Checking for standard version of getpwuid_r... Yes. Checking for standard version of asctime_r... Yes. Checking for rpath support... Yes. Checking for -Wl,--as-needed... Yes. Checking for available C++ compiler warning flags... -Wall -Wextra -Wwrite-strings Checking for available C compiler warning flags... -Wall -Wextra -Wwrite-strings -Wmissing-declarations so this particular issue seems to be fixed, right? I had some other issues with 0.18 though. 1. pkgsrc's copy of rst2man is called "rst2man.py". The configure test for this fails, of course, and there is another place where rst2man is called directly. I've changed that to rst2man.py locally, but it'd be good if configure could test for both names, set a variable to the one found, and use the variable in the other place. 2. doc/Makefile.local has "python" hardcoded. pkgsrc supports multiple python versions at the same time, with the disadvantage that there is no "python" executable, only "python2.6", "python2.7", "python3.3" etc. I've passed in the proper executable name as PYTHONBIN and used it in the Makefile. 3. installation of notmuch-version.el fails, because the install rule has no dependency on the generated file notmuch-version.el. I've added such a dependency. The patches I used to make notmuch build are attached, but I can of course test other patches if you prefer different solutions. I haven't really run this version of notmuch yet. Cheers, Thomas -- next part -- $NetBSD$ --- doc/Makefile.local.orig 2014-05-06 07:27:29.0 + +++ doc/Makefile.local @@ -7,8 +7,8 @@ SPHINXOPTS:= -q SPHINXBUILD = sphinx-build DOCBUILDDIR := $(dir)/_build -prerst2man := python $(srcdir)/$(dir)/prerst2man.py -mkdocdeps := python $(srcdir)/$(dir)/mkdocdeps.py +prerst2man := ${PYTHONBIN} $(srcdir)/$(dir)/prerst2man.py +mkdocdeps := ${PYTHONBIN} $(srcdir)/$(dir)/mkdocdeps.py # Internal variables. ALLSPHINXOPTS := -d $(DOCBUILDDIR)/doctrees $(SPHINXOPTS) $(srcdir)/$(dir) -- next part -- $NetBSD$ --- doc/prerst2man.py.orig 2014-05-06 07:27:29.0 + +++ doc/prerst2man.py @@ -59,5 +59,5 @@ for page in man_pages: outfile.write("".join(lines)) outfile.close() -system('set -x; rst2man {0} {1}/{2}.{3}' +system('set -x; rst2man.py {0} {1}/{2}.{3}' .format(filename, outdir, page[0], page[4])) -- next part -- $NetBSD$ --- emacs/Makefile.local.orig 2014-05-06 07:27:29.0 + +++ emacs/Makefile.local @@ -69,7 +69,7 @@ install: install-emacs endif .PHONY: install-emacs -install-emacs: +install-emacs: $(dir)/notmuch-version.el mkdir -p "$(DESTDIR)$(emacslispdir)" install -m0644 $(emacs_sources) "$(DESTDIR)$(emacslispdir)" ifeq ($(HAVE_EMACS),1) -- next part -- $NetBSD: patch-aa,v 1.1 2014/01/09 12:15:23 wiz Exp $ --- configure.orig 2014-05-06 07:27:29.0 + +++ configure @@ -418,7 +418,7 @@ else have_sphinx=0 printf "Checking if rst2man is available... " -if rst2man -V > /dev/null 2>&1; then +if rst2man.py -V > /dev/null 2>&1; then printf "Yes.\n" have_rst2man=1 else
notmuch-0.18 issues [was Re: notmuch-0.16: realpath() compatibility issue; clang visibility problem]
Hi David! Thanks for getting back to me about this. Currently configure (with some patches) says: Checking for Xapian development files... Yes (1.2.17). Checking for Xapian compaction support... Yes. Checking for GMime development files... Yes (gmime-2.4 ). Checking for Glib development files (>= 2.22)... Yes. Checking for zlib (>= 1.2.5.2)... Yes. Checking for talloc development files... Yes. Checking for valgrind development files... No (but that's fine). Checking for bash-completion (>= 1.90)... No (will not install bash completion). Checking if emacs is available... emacs: not found No (so will not byte-compile emacs code) Checking if sphinx is available and supports nroff output... python: not found No (falling back to rst2man). Checking if rst2man is available... Yes. Checking which platform we are on... Unknown. *** Warning: Unknown platform. Notmuch might or might not build correctly. Checking byte order... 1234 Checking for canonicalize_file_name... No (will use our own instead). Checking for getline... Yes. Checking for strcasestr... Yes. Checking for strsep... Yes. Checking for timegm... Yes. Checking for dirent.d_type... Yes. Checking for standard version of getpwuid_r... Yes. Checking for standard version of asctime_r... Yes. Checking for rpath support... Yes. Checking for -Wl,--as-needed... Yes. Checking for available C++ compiler warning flags... -Wall -Wextra -Wwrite-strings Checking for available C compiler warning flags... -Wall -Wextra -Wwrite-strings -Wmissing-declarations so this particular issue seems to be fixed, right? I had some other issues with 0.18 though. 1. pkgsrc's copy of rst2man is called "rst2man.py". The configure test for this fails, of course, and there is another place where rst2man is called directly. I've changed that to rst2man.py locally, but it'd be good if configure could test for both names, set a variable to the one found, and use the variable in the other place. 2. doc/Makefile.local has "python" hardcoded. pkgsrc supports multiple python versions at the same time, with the disadvantage that there is no "python" executable, only "python2.6", "python2.7", "python3.3" etc. I've passed in the proper executable name as PYTHONBIN and used it in the Makefile. 3. installation of notmuch-version.el fails, because the install rule has no dependency on the generated file notmuch-version.el. I've added such a dependency. The patches I used to make notmuch build are attached, but I can of course test other patches if you prefer different solutions. I haven't really run this version of notmuch yet. Cheers, Thomas$NetBSD$ --- doc/Makefile.local.orig 2014-05-06 07:27:29.0 + +++ doc/Makefile.local @@ -7,8 +7,8 @@ SPHINXOPTS:= -q SPHINXBUILD = sphinx-build DOCBUILDDIR := $(dir)/_build -prerst2man := python $(srcdir)/$(dir)/prerst2man.py -mkdocdeps := python $(srcdir)/$(dir)/mkdocdeps.py +prerst2man := ${PYTHONBIN} $(srcdir)/$(dir)/prerst2man.py +mkdocdeps := ${PYTHONBIN} $(srcdir)/$(dir)/mkdocdeps.py # Internal variables. ALLSPHINXOPTS := -d $(DOCBUILDDIR)/doctrees $(SPHINXOPTS) $(srcdir)/$(dir) $NetBSD$ --- doc/prerst2man.py.orig 2014-05-06 07:27:29.0 + +++ doc/prerst2man.py @@ -59,5 +59,5 @@ for page in man_pages: outfile.write("".join(lines)) outfile.close() -system('set -x; rst2man {0} {1}/{2}.{3}' +system('set -x; rst2man.py {0} {1}/{2}.{3}' .format(filename, outdir, page[0], page[4])) $NetBSD$ --- emacs/Makefile.local.orig 2014-05-06 07:27:29.0 + +++ emacs/Makefile.local @@ -69,7 +69,7 @@ install: install-emacs endif .PHONY: install-emacs -install-emacs: +install-emacs: $(dir)/notmuch-version.el mkdir -p "$(DESTDIR)$(emacslispdir)" install -m0644 $(emacs_sources) "$(DESTDIR)$(emacslispdir)" ifeq ($(HAVE_EMACS),1) $NetBSD: patch-aa,v 1.1 2014/01/09 12:15:23 wiz Exp $ --- configure.orig 2014-05-06 07:27:29.0 + +++ configure @@ -418,7 +418,7 @@ else have_sphinx=0 printf "Checking if rst2man is available... " -if rst2man -V > /dev/null 2>&1; then +if rst2man.py -V > /dev/null 2>&1; then printf "Yes.\n" have_rst2man=1 else ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
notmuch-0.16: realpath() compatibility issue; clang visibility problem
On Sat, Jan 04, 2014 at 09:18:15AM -0400, David Bremner wrote: > Thomas Klausner writes: > > > ^ > > ./lib/notmuch-private.h:52:13: note: previous attribute is here > > #pragma GCC visibility push(hidden) > > ^ > > The clang related issues might be fixed in 0.17; can you try that (or > git master)? Yes, 0.17 fixed that problem. > > size_t length; > > -char *data, *filename; > > +char *data, filename[MAXPATHLEN]; > > GError *error = NULL; > > I'm not sure what the right answer is here. MATHPATHLEN (and PATH_MAX) > are not necessarily defined; in particular this would break > compilation on GNU Hurd. Perhaps we should ship a compatibility > implementation of a POSIX.1-2008 compatible [1] realpath. Or maybe > realpath can be avoided completely here. A compatibility implementation for POSIX.1-2008-realpath would be great, as would be avoiding the call. Why is it necessary to resolve $HOME here? > > + strcpy(filename, config->filename); > > Any reason not to use strncpy here? You're right, that'd be better here. > Of course bug reports and fixes in any form are always welcome, but even > more appreciated if they roughly follow [2]; mainly patches from git > with sensible commit messages, and some minor coding style issues. Thanks for the comments, Thomas
Re: notmuch-0.16: realpath() compatibility issue; clang visibility problem
On Sat, Jan 04, 2014 at 09:18:15AM -0400, David Bremner wrote: > Thomas Klausner writes: > > > ^ > > ./lib/notmuch-private.h:52:13: note: previous attribute is here > > #pragma GCC visibility push(hidden) > > ^ > > The clang related issues might be fixed in 0.17; can you try that (or > git master)? Yes, 0.17 fixed that problem. > > size_t length; > > -char *data, *filename; > > +char *data, filename[MAXPATHLEN]; > > GError *error = NULL; > > I'm not sure what the right answer is here. MATHPATHLEN (and PATH_MAX) > are not necessarily defined; in particular this would break > compilation on GNU Hurd. Perhaps we should ship a compatibility > implementation of a POSIX.1-2008 compatible [1] realpath. Or maybe > realpath can be avoided completely here. A compatibility implementation for POSIX.1-2008-realpath would be great, as would be avoiding the call. Why is it necessary to resolve $HOME here? > > + strcpy(filename, config->filename); > > Any reason not to use strncpy here? You're right, that'd be better here. > Of course bug reports and fixes in any form are always welcome, but even > more appreciated if they roughly follow [2]; mainly patches from git > with sensible commit messages, and some minor coding style issues. Thanks for the comments, Thomas ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
notmuch-0.16: realpath() compatibility issue; clang visibility problem
On Sat, Jan 04, 2014 at 03:06:38PM +0200, Tomi Ollila wrote: > The linux namual page (*) has good explanation of this in the BUGS section > > (*) http://man7.org/linux/man-pages/man3/realpath.3.html > > After reading that I think fixing that is not as simple as your previous > patch does it -- so probably you just have to keep patching your system > until NetBSD library realpath() is POSIX.1-2008 -compatible. Ok, so it's not that easy in general. On the other hand, I wonder how many systems support POSIX.1-2008 realpath() :) > Note that having users' own patches in their systems is not uncommon > at all :D I've filed a bug report in the meantime: http://gnats.netbsd.org/48497 Thanks for the comments, Thomas
notmuch-0.16: realpath() compatibility issue; clang visibility problem
On Sat, Jan 04, 2014 at 02:46:37PM +0200, Jani Nikula wrote: > I guess we should look at realpath() compatibility, but in fairness passing > NULL for the second parameter is according to POSIX.1-2008, not glibc > extension. Ah, interesting. I can file a bug report with NetBSD about that, but in the meantime, it causes a coredump. :| Thanks, Thomas
notmuch-0.16: realpath() compatibility issue; clang visibility problem
On Sat, Jan 04, 2014 at 02:35:54PM +0200, Jani Nikula wrote: > For the visibility issue please upgrade Notmuch. Thanks. It seems 0.17 came out a short time after I downloaded notmuch :) I don't need the visibility patch with that version any longer. Thomas
Re: notmuch-0.16: realpath() compatibility issue; clang visibility problem
On Sat, Jan 04, 2014 at 03:06:38PM +0200, Tomi Ollila wrote: > The linux namual page (*) has good explanation of this in the BUGS section > > (*) http://man7.org/linux/man-pages/man3/realpath.3.html > > After reading that I think fixing that is not as simple as your previous > patch does it -- so probably you just have to keep patching your system > until NetBSD library realpath() is POSIX.1-2008 -compatible. Ok, so it's not that easy in general. On the other hand, I wonder how many systems support POSIX.1-2008 realpath() :) > Note that having users' own patches in their systems is not uncommon > at all :D I've filed a bug report in the meantime: http://gnats.netbsd.org/48497 Thanks for the comments, Thomas ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: notmuch-0.16: realpath() compatibility issue; clang visibility problem
On Sat, Jan 04, 2014 at 02:35:54PM +0200, Jani Nikula wrote: > For the visibility issue please upgrade Notmuch. Thanks. It seems 0.17 came out a short time after I downloaded notmuch :) I don't need the visibility patch with that version any longer. Thomas ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: notmuch-0.16: realpath() compatibility issue; clang visibility problem
On Sat, Jan 04, 2014 at 02:46:37PM +0200, Jani Nikula wrote: > I guess we should look at realpath() compatibility, but in fairness passing > NULL for the second parameter is according to POSIX.1-2008, not glibc > extension. Ah, interesting. I can file a bug report with NetBSD about that, but in the meantime, it causes a coredump. :| Thanks, Thomas ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
notmuch-0.16: realpath() compatibility issue; clang visibility problem
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 $NetBSD$ NULL as second argument for realpath() is only supported in glibc. Use more portable code. --- notmuch-config.c.orig 2013-08-03 11:29:40.0 + +++ notmuch-config.c @@ -23,6 +23,8 @@ #include #include #include +#include +#include static const char toplevel_config_comment[] = " .notmuch-config - Configuration file for the notmuch mail system\n" @@ -444,7 +446,7 @@ int notmuch_config_save (notmuch_config_t *config) { size_t length; -char *data, *filename; +char *data, filename[MAXPATHLEN]; GError *error = NULL; data = g_key_file_to_data (config->key_file, &length, NULL); @@ -454,15 +456,9 @@ notmuch_config_save (notmuch_config_t *c } /* Try not to overwrite symlinks. */ -filename = realpath (config->filename, NULL); -if (! filename) { +if (! realpath (config->filename, filename)) { if (errno == ENOENT) { - filename = strdup (config->filename); - if (! filename) { - fprintf (stderr, "Out of memory.\n"); - g_free (data); - return 1; - } + strcpy(filename, config->filename); } else { fprintf (stderr, "Error canonicalizing %s: %s\n", config->filename, strerror (errno)); @@ -480,12 +476,10 @@ notmuch_config_save (notmuch_config_t *c filename, error->message); } g_error_free (error); - free (filename); g_free (data); return 1; } -free (filename); g_free (data); return 0; } $NetBSD$ Doesn't compile with clang. --- lib/notmuch-private.h.orig 2013-08-03 11:29:40.0 + +++ lib/notmuch-private.h @@ -64,7 +64,7 @@ NOTMUCH_BEGIN_DECLS #define unused(x) x __attribute__ ((unused)) #ifdef __cplusplus -# define visible __attribute__((visibility("default"))) +# define visible #else # define visible #endif ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
notmuch-0.16: realpath() compatibility issue; clang visibility problem
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 -- next part -- $NetBSD$ NULL as second argument for realpath() is only supported in glibc. Use more portable code. --- notmuch-config.c.orig 2013-08-03 11:29:40.0 + +++ notmuch-config.c @@ -23,6 +23,8 @@ #include #include #include +#include +#include static const char toplevel_config_comment[] = " .notmuch-config - Configuration file for the notmuch mail system\n" @@ -444,7 +446,7 @@ int notmuch_config_save (notmuch_config_t *config) { size_t length; -char *data, *filename; +char *data, filename[MAXPATHLEN]; GError *error = NULL; data = g_key_file_to_data (config->key_file, &length, NULL); @@ -454,15 +456,9 @@ notmuch_config_save (notmuch_config_t *c } /* Try not to overwrite symlinks. */ -filename = realpath (config->filename, NULL); -if (! filename) { +if (! realpath (config->filename, filename)) { if (errno == ENOENT) { - filename = strdup (config->filename); - if (! filename) { - fprintf (stderr, "Out of memory.\n"); - g_free (data); - return 1; - } + strcpy(filename, config->filename); } else { fprintf (stderr, "Error canonicalizing %s: %s\n", config->filename, strerror (errno)); @@ -480,12 +476,10 @@ notmuch_config_save (notmuch_config_t *c filename, error->message); } g_error_free (error); - free (filename); g_free (data); return 1; } -free (filename); g_free (data); return 0; } -- next part -- $NetBSD$ Doesn't compile with clang. --- lib/notmuch-private.h.orig 2013-08-03 11:29:40.0 + +++ lib/notmuch-private.h @@ -64,7 +64,7 @@ NOTMUCH_BEGIN_DECLS #define unused(x) x __attribute__ ((unused)) #ifdef __cplusplus -# define visible __attribute__((visibility("default"))) +# define visible #else # define visible #endif