Re: notmuch-0.16: realpath() compatibility issue; clang visibility problem
For the visibility issue please upgrade Notmuch.
BR,
Jani.
On Jan 4, 2014 2:26 PM, "Thomas Klausner" wrote:
>
> 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
>
> ___
> notmuch mailing list
> notmuch@notmuchmail.org
> http://notmuchmail.org/mailman/listinfo/notmuch
>
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
Re: notmuch-0.16: realpath() compatibility issue; clang visibility problem
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.
On Jan 4, 2014 2:35 PM, "Jani Nikula" wrote:
>
> For the visibility issue please upgrade Notmuch.
>
> BR,
> Jani.
>
> On Jan 4, 2014 2:26 PM, "Thomas Klausner" wrote:
> >
> > 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
> >
> > ___
> > notmuch mailing list
> > notmuch@notmuchmail.org
> > http://notmuchmail.org/mailman/listinfo/notmuch
> >
___
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
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, Thomas Klausner wrote: > 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. :| 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. Note that having users' own patches in their systems is not uncommon at all :D > > Thanks, > Thomas Tomi ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: notmuch-0.16: realpath() compatibility issue; clang visibility problem
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)? > 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. > + strcpy(filename, config->filename); Any reason not to use strncpy 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. cheers, d [1]: http://pubs.opengroup.org/onlinepubs/9699919799/ [2]: http://notmuchmail.org/contributing/ ___ 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 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 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
Re: notmuch-0.16: realpath() compatibility issue; clang visibility problem
On Jan 5, 2014 12:38 AM, "Thomas Klausner" wrote: > > On Sat, Jan 04, 2014 at 09:18:15AM -0400, David Bremner wrote: > > 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? realpath is used to follow, not overwrite symlinks. ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: notmuch-0.16: realpath() compatibility issue; clang visibility problem
Thomas Klausner writes: > > Debugging it I found that notmuch uses a glibc extension to realpath, > allowing NULL as second argument. > This should be fixed in commit af5c3af ; I'd appreciate if you can test it. d ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: notmuch-0.16: realpath() compatibility issue; clang visibility problem
Thomas Klausner writes: > Hi David! > > On Tue, Apr 08, 2014 at 08:26:25AM -0300, David Bremner wrote: >> > Debugging it I found that notmuch uses a glibc extension to realpath, >> > allowing NULL as second argument. >> > >> >> This should be fixed in commit af5c3af ; I'd appreciate if you can test >> it. > > Thanks. Not completely yet. > > clang++ command-line-arguments.o debugger.o gmime-filter-reply.o hooks.o > notmuch.o notmuch-compact.o notmuch-config.o notmuch-count.o notmuch-dump.o > notmuch-insert.o notmuch-new.o notmuch-reply.o notmuch-restore.o > notmuch-search.o notmuch-setup.o notmuch-show.o notmuch-tag.o notmuch-time.o > sprinter-json.o sprinter-sexp.o sprinter-text.o query-string.o mime-node.o > crypto.o tag-util.o -Lutil -lutil -Llib -lnotmuch -Wl,--as-needed > -L/usr/pkg/lib -Wl,-R/usr/pkg/lib -lgmime-2.4 -Wl,-R/usr/pkg/lib > -lgobject-2.0 -Wl,-R/usr/pkg/lib -lglib-2.0 -lintl -L/usr/pkg/lib > -Wl,-rpath,/usr/pkg/lib -Wl,-R/usr/pkg/lib -ltalloc -L/usr/pkg/lib > -Wl,-R/usr/pkg/lib -lgmime-2.4 -Wl,-R/usr/pkg/lib -lgobject-2.0 > -Wl,-R/usr/pkg/lib -lglib-2.0 -lintl -L/usr/pkg/lib -Wl,-rpath,/usr/pkg/lib > -Wl,-R/usr/pkg/lib -ltalloc -Wl,-R/usr/pkg/lib -L/usr/pkg/lib -lxapian > -L/usr/pkg/lib -lz -luuid -Wl,--enable-new-dtags -Wl,-rpath,/usr/local/lib -o > notmuch-shared > notmuch-config.o: In function `notmuch_config_save': > notmuch-config.c:(.text+0xd03): undefined reference to > `canonicalize_file_name' > clang: error: linker command failed with exit code 1 (use -v to see > invocation) > Makefile.local:287: recipe for target 'notmuch-shared' failed > gmake: *** [notmuch-shared] Error 1 Sorry this got dropped. That's what happens to mail sent to me personally :(. I'm assuming it's ok forward this output to the list. Is it correct that the statically linked version (notmuch) worked OK but the dynamically linked version (notmuch-shared) failed? That's consistent with what I observe on Debian, it's just that here the dynamically linked version falls back on the canonicalize_file_name in glibc, hiding the error. For people on glibc platforms who want to play with this, set HAVE_CANONICALIZE_FILE_NAME=0 in Makefile.config, make clean, make % nm notmuch-shared | grep canonicalize d ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: notmuch-0.16: realpath() compatibility issue; clang visibility problem
David Bremner writes: > Is it correct that the statically linked version (notmuch) worked OK but > the dynamically linked version (notmuch-shared) failed? That's > consistent with what I observe on Debian, it's just that here the > dynamically linked version falls back on the canonicalize_file_name in > glibc, hiding the error. Actually I'm wrong about this part. or at least I don't know how to test this on a glibc based system. My suggested test with nm is bogus, since all symbols from libnotmuch.so will show up the same way. d ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: notmuch-0.16: realpath() compatibility issue; clang visibility problem
Thomas Klausner writes: > 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. This exact bug was fixed long ago, tagging fixed in nmbug. ___ 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$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.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]
On Thu, Jun 26 2014, Thomas Klausner wrote: > > 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. There are patches to be reviewed for this. > > 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. For this we could figure out something... > > 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. This has been fixed in 0.18.1. > > 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$ > Tomi
notmuch-0.18 issues [was Re: notmuch-0.16: realpath() compatibility issue; clang visibility problem]
Thomas Klausner writes: > 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? > If notmuch-shared links for you now, perhaps commit 3242e29 was the fix needed. That commit makes the compat version canonicalize_file_name exported from the libnotmuch.so. I have no real idea how the symbol visibility stuff interacts with clang though. d
Re: notmuch-0.18 issues [was Re: notmuch-0.16: realpath() compatibility issue; clang visibility problem]
On Thu, Jun 26 2014, Thomas Klausner wrote: > > 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. There are patches to be reviewed for this. > > 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. For this we could figure out something... > > 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. This has been fixed in 0.18.1. > > 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$ > Tomi ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: notmuch-0.18 issues [was Re: notmuch-0.16: realpath() compatibility issue; clang visibility problem]
Thomas Klausner writes: > 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? > If notmuch-shared links for you now, perhaps commit 3242e29 was the fix needed. That commit makes the compat version canonicalize_file_name exported from the libnotmuch.so. I have no real idea how the symbol visibility stuff interacts with clang though. d ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: notmuch-0.18 issues [was Re: notmuch-0.16: realpath() compatibility issue; clang visibility problem]
Thomas Klausner writes: > > 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. > 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 could look at a rename of libutil.a. 'libmyutil.a' is not really nice, but I guess we could use libnmutil.a or libnotmuch_util.a. Any upstream contributors with opinions on what colour we should paint this particular unicycle shed? d [1]: http://ftp.netbsd.org/pub/pkgsrc/current/pkgsrc/mail/notmuch/patches/ ___ 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, 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. My 3-year old "supportive patch" https://notmuchmail.org/pipermail/notmuch/2014/017918.html still works nicely (building with it on one system and using in two). > could look at a rename of libutil.a. 'libmyutil.a' is not really nice, > but I guess we could use libnmutil.a or libnotmuch_util.a. > > Any upstream contributors with opinions on what colour we should paint > this particular unicycle shed? From those 2 my vote would be libnotmuch_util.a. I'd think more of it but I probably forget. > > d > > [1]: http://ftp.netbsd.org/pub/pkgsrc/current/pkgsrc/mail/notmuch/patches/ Tomi ___ 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
