* notmuch-0.16: realpath() compatibility issue; clang visibility problem
@ 2014-01-03 21:47 Thomas Klausner
2014-01-04 12:35 ` Jani Nikula
` (3 more replies)
0 siblings, 4 replies; 20+ messages in thread
From: Thomas Klausner @ 2014-01-03 21:47 UTC (permalink / raw)
To: notmuch
[-- Attachment #1: Type: text/plain, Size: 2337 bytes --]
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
[-- Attachment #2: patch-notmuch-config.c --]
[-- Type: text/plain, Size: 1497 bytes --]
$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.000000000 +0000
+++ notmuch-config.c
@@ -23,6 +23,8 @@
#include <pwd.h>
#include <netdb.h>
#include <assert.h>
+#include <sys/param.h>
+#include <stdlib.h>
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;
}
[-- Attachment #3: patch-lib_notmuch-private.h --]
[-- Type: text/plain, Size: 346 bytes --]
$NetBSD$
Doesn't compile with clang.
--- lib/notmuch-private.h.orig 2013-08-03 11:29:40.000000000 +0000
+++ 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
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: notmuch-0.16: realpath() compatibility issue; clang visibility problem
2014-01-03 21:47 notmuch-0.16: realpath() compatibility issue; clang visibility problem Thomas Klausner
@ 2014-01-04 12:35 ` Jani Nikula
2014-01-04 12:46 ` Jani Nikula
2014-01-04 12:52 ` Thomas Klausner
2014-01-04 13:18 ` David Bremner
` (2 subsequent siblings)
3 siblings, 2 replies; 20+ messages in thread
From: Jani Nikula @ 2014-01-04 12:35 UTC (permalink / raw)
To: Thomas Klausner; +Cc: Notmuch Mail
[-- Attachment #1: Type: text/plain, Size: 2726 bytes --]
For the visibility issue please upgrade Notmuch.
BR,
Jani.
On Jan 4, 2014 2:26 PM, "Thomas Klausner" <tk@giga.or.at> 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
>
[-- Attachment #2: Type: text/html, Size: 3617 bytes --]
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: notmuch-0.16: realpath() compatibility issue; clang visibility problem
2014-01-04 12:35 ` Jani Nikula
@ 2014-01-04 12:46 ` Jani Nikula
2014-01-04 12:53 ` Thomas Klausner
2014-01-04 12:52 ` Thomas Klausner
1 sibling, 1 reply; 20+ messages in thread
From: Jani Nikula @ 2014-01-04 12:46 UTC (permalink / raw)
To: Thomas Klausner; +Cc: Notmuch Mail
[-- Attachment #1: Type: text/plain, Size: 3089 bytes --]
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" <jani@nikula.org> wrote:
>
> For the visibility issue please upgrade Notmuch.
>
> BR,
> Jani.
>
> On Jan 4, 2014 2:26 PM, "Thomas Klausner" <tk@giga.or.at> 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
> >
[-- Attachment #2: Type: text/html, Size: 4266 bytes --]
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: notmuch-0.16: realpath() compatibility issue; clang visibility problem
2014-01-04 12:35 ` Jani Nikula
2014-01-04 12:46 ` Jani Nikula
@ 2014-01-04 12:52 ` Thomas Klausner
1 sibling, 0 replies; 20+ messages in thread
From: Thomas Klausner @ 2014-01-04 12:52 UTC (permalink / raw)
To: Jani Nikula; +Cc: Notmuch Mail
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
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: notmuch-0.16: realpath() compatibility issue; clang visibility problem
2014-01-04 12:46 ` Jani Nikula
@ 2014-01-04 12:53 ` Thomas Klausner
2014-01-04 13:06 ` Tomi Ollila
0 siblings, 1 reply; 20+ messages in thread
From: Thomas Klausner @ 2014-01-04 12:53 UTC (permalink / raw)
To: Jani Nikula; +Cc: Notmuch Mail
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
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: notmuch-0.16: realpath() compatibility issue; clang visibility problem
2014-01-04 12:53 ` Thomas Klausner
@ 2014-01-04 13:06 ` Tomi Ollila
2014-01-04 13:28 ` Thomas Klausner
0 siblings, 1 reply; 20+ messages in thread
From: Tomi Ollila @ 2014-01-04 13:06 UTC (permalink / raw)
To: Thomas Klausner; +Cc: Notmuch Mail
On Sat, Jan 04 2014, Thomas Klausner <tk@giga.or.at> 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
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: notmuch-0.16: realpath() compatibility issue; clang visibility problem
2014-01-03 21:47 notmuch-0.16: realpath() compatibility issue; clang visibility problem Thomas Klausner
2014-01-04 12:35 ` Jani Nikula
@ 2014-01-04 13:18 ` David Bremner
2014-01-04 22:37 ` Thomas Klausner
2014-04-08 11:26 ` David Bremner
2017-03-12 16:00 ` notmuch-0.16: realpath() compatibility issue; clang visibility problem David Bremner
3 siblings, 1 reply; 20+ messages in thread
From: David Bremner @ 2014-01-04 13:18 UTC (permalink / raw)
To: Thomas Klausner, notmuch
Thomas Klausner <tk@giga.or.at> 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/
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: notmuch-0.16: realpath() compatibility issue; clang visibility problem
2014-01-04 13:06 ` Tomi Ollila
@ 2014-01-04 13:28 ` Thomas Klausner
0 siblings, 0 replies; 20+ messages in thread
From: Thomas Klausner @ 2014-01-04 13:28 UTC (permalink / raw)
To: Tomi Ollila; +Cc: Notmuch Mail
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
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: notmuch-0.16: realpath() compatibility issue; clang visibility problem
2014-01-04 13:18 ` David Bremner
@ 2014-01-04 22:37 ` Thomas Klausner
2014-01-04 22:53 ` Jani Nikula
0 siblings, 1 reply; 20+ messages in thread
From: Thomas Klausner @ 2014-01-04 22:37 UTC (permalink / raw)
To: David Bremner; +Cc: notmuch
On Sat, Jan 04, 2014 at 09:18:15AM -0400, David Bremner wrote:
> Thomas Klausner <tk@giga.or.at> 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
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: notmuch-0.16: realpath() compatibility issue; clang visibility problem
2014-01-04 22:37 ` Thomas Klausner
@ 2014-01-04 22:53 ` Jani Nikula
0 siblings, 0 replies; 20+ messages in thread
From: Jani Nikula @ 2014-01-04 22:53 UTC (permalink / raw)
To: Thomas Klausner; +Cc: Notmuch Mail
[-- Attachment #1: Type: text/plain, Size: 664 bytes --]
On Jan 5, 2014 12:38 AM, "Thomas Klausner" <tk@giga.or.at> 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.
[-- Attachment #2: Type: text/html, Size: 853 bytes --]
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: notmuch-0.16: realpath() compatibility issue; clang visibility problem
2014-01-03 21:47 notmuch-0.16: realpath() compatibility issue; clang visibility problem Thomas Klausner
2014-01-04 12:35 ` Jani Nikula
2014-01-04 13:18 ` David Bremner
@ 2014-04-08 11:26 ` David Bremner
[not found] ` <20140408123312.GZ5053@danbala.tuwien.ac.at>
2017-03-12 16:00 ` notmuch-0.16: realpath() compatibility issue; clang visibility problem David Bremner
3 siblings, 1 reply; 20+ messages in thread
From: David Bremner @ 2014-04-08 11:26 UTC (permalink / raw)
To: Thomas Klausner, notmuch
Thomas Klausner <tk@giga.or.at> 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
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: notmuch-0.16: realpath() compatibility issue; clang visibility problem
[not found] ` <20140408123312.GZ5053@danbala.tuwien.ac.at>
@ 2014-06-26 12:02 ` David Bremner
2014-06-26 12:52 ` David Bremner
2014-06-26 13:08 ` notmuch-0.18 issues [was Re: notmuch-0.16: realpath() compatibility issue; clang visibility problem] Thomas Klausner
0 siblings, 2 replies; 20+ messages in thread
From: David Bremner @ 2014-06-26 12:02 UTC (permalink / raw)
To: Thomas Klausner; +Cc: Notmuch list
Thomas Klausner <tk@giga.or.at> 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
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: notmuch-0.16: realpath() compatibility issue; clang visibility problem
2014-06-26 12:02 ` David Bremner
@ 2014-06-26 12:52 ` David Bremner
2014-06-26 13:08 ` notmuch-0.18 issues [was Re: notmuch-0.16: realpath() compatibility issue; clang visibility problem] Thomas Klausner
1 sibling, 0 replies; 20+ messages in thread
From: David Bremner @ 2014-06-26 12:52 UTC (permalink / raw)
To: Thomas Klausner; +Cc: Notmuch list
David Bremner <david@tethera.net> 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
^ permalink raw reply [flat|nested] 20+ messages in thread
* notmuch-0.18 issues [was Re: notmuch-0.16: realpath() compatibility issue; clang visibility problem]
2014-06-26 12:02 ` David Bremner
2014-06-26 12:52 ` David Bremner
@ 2014-06-26 13:08 ` Thomas Klausner
2014-06-26 13:16 ` Tomi Ollila
` (2 more replies)
1 sibling, 3 replies; 20+ messages in thread
From: Thomas Klausner @ 2014-06-26 13:08 UTC (permalink / raw)
To: David Bremner; +Cc: Notmuch list
[-- Attachment #1: Type: text/plain, Size: 2622 bytes --]
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
[-- Attachment #2: patch-doc_Makefile.local --]
[-- Type: text/plain, Size: 523 bytes --]
$NetBSD$
--- doc/Makefile.local.orig 2014-05-06 07:27:29.000000000 +0000
+++ 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)
[-- Attachment #3: patch-doc_prerst2man.py --]
[-- Type: text/plain, Size: 346 bytes --]
$NetBSD$
--- doc/prerst2man.py.orig 2014-05-06 07:27:29.000000000 +0000
+++ 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]))
[-- Attachment #4: patch-emacs_Makefile.local --]
[-- Type: text/plain, Size: 357 bytes --]
$NetBSD$
--- emacs/Makefile.local.orig 2014-05-06 07:27:29.000000000 +0000
+++ 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)
[-- Attachment #5: patch-configure --]
[-- Type: text/plain, Size: 365 bytes --]
$NetBSD: patch-aa,v 1.1 2014/01/09 12:15:23 wiz Exp $
--- configure.orig 2014-05-06 07:27:29.000000000 +0000
+++ 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
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: notmuch-0.18 issues [was Re: notmuch-0.16: realpath() compatibility issue; clang visibility problem]
2014-06-26 13:08 ` notmuch-0.18 issues [was Re: notmuch-0.16: realpath() compatibility issue; clang visibility problem] Thomas Klausner
@ 2014-06-26 13:16 ` Tomi Ollila
2014-06-26 15:00 ` David Bremner
2017-03-12 16:21 ` David Bremner
2 siblings, 0 replies; 20+ messages in thread
From: Tomi Ollila @ 2014-06-26 13:16 UTC (permalink / raw)
To: Thomas Klausner, David Bremner; +Cc: Notmuch list
On Thu, Jun 26 2014, Thomas Klausner <tk@giga.or.at> 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
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: notmuch-0.18 issues [was Re: notmuch-0.16: realpath() compatibility issue; clang visibility problem]
2014-06-26 13:08 ` notmuch-0.18 issues [was Re: notmuch-0.16: realpath() compatibility issue; clang visibility problem] Thomas Klausner
2014-06-26 13:16 ` Tomi Ollila
@ 2014-06-26 15:00 ` David Bremner
2017-03-12 16:21 ` David Bremner
2 siblings, 0 replies; 20+ messages in thread
From: David Bremner @ 2014-06-26 15:00 UTC (permalink / raw)
To: Thomas Klausner; +Cc: Notmuch list
Thomas Klausner <tk@giga.or.at> 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
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: notmuch-0.16: realpath() compatibility issue; clang visibility problem
2014-01-03 21:47 notmuch-0.16: realpath() compatibility issue; clang visibility problem Thomas Klausner
` (2 preceding siblings ...)
2014-04-08 11:26 ` David Bremner
@ 2017-03-12 16:00 ` David Bremner
3 siblings, 0 replies; 20+ messages in thread
From: David Bremner @ 2017-03-12 16:00 UTC (permalink / raw)
To: Thomas Klausner, notmuch
Thomas Klausner <tk@giga.or.at> 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.
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: notmuch-0.18 issues [was Re: notmuch-0.16: realpath() compatibility issue; clang visibility problem]
2014-06-26 13:08 ` notmuch-0.18 issues [was Re: notmuch-0.16: realpath() compatibility issue; clang visibility problem] Thomas Klausner
2014-06-26 13:16 ` Tomi Ollila
2014-06-26 15:00 ` David Bremner
@ 2017-03-12 16:21 ` David Bremner
2017-03-12 17:24 ` Tomi Ollila
2 siblings, 1 reply; 20+ messages in thread
From: David Bremner @ 2017-03-12 16:21 UTC (permalink / raw)
To: Thomas Klausner; +Cc: Notmuch list
Thomas Klausner <tk@giga.or.at> 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/
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: notmuch-0.18 issues [was Re: notmuch-0.16: realpath() compatibility issue; clang visibility problem]
2017-03-12 16:21 ` David Bremner
@ 2017-03-12 17:24 ` Tomi Ollila
2017-03-12 20:52 ` Thomas Klausner
0 siblings, 1 reply; 20+ messages in thread
From: Tomi Ollila @ 2017-03-12 17:24 UTC (permalink / raw)
To: David Bremner, Thomas Klausner; +Cc: Notmuch list
On Sun, Mar 12 2017, David Bremner <david@tethera.net> wrote:
> Thomas Klausner <tk@giga.or.at> 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
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: notmuch-0.18 issues [was Re: notmuch-0.16: realpath() compatibility issue; clang visibility problem]
2017-03-12 17:24 ` Tomi Ollila
@ 2017-03-12 20:52 ` Thomas Klausner
0 siblings, 0 replies; 20+ messages in thread
From: Thomas Klausner @ 2017-03-12 20:52 UTC (permalink / raw)
To: Tomi Ollila; +Cc: David Bremner, Notmuch list
On Sun, Mar 12, 2017 at 07:24:53PM +0200, Tomi Ollila wrote:
> On Sun, Mar 12 2017, David Bremner <david@tethera.net> wrote:
>
> > Thomas Klausner <tk@giga.or.at> 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
^ permalink raw reply [flat|nested] 20+ messages in thread
end of thread, other threads:[~2017-03-12 20:58 UTC | newest]
Thread overview: 20+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-01-03 21:47 notmuch-0.16: realpath() compatibility issue; clang visibility problem Thomas Klausner
2014-01-04 12:35 ` Jani Nikula
2014-01-04 12:46 ` Jani Nikula
2014-01-04 12:53 ` Thomas Klausner
2014-01-04 13:06 ` Tomi Ollila
2014-01-04 13:28 ` Thomas Klausner
2014-01-04 12:52 ` Thomas Klausner
2014-01-04 13:18 ` David Bremner
2014-01-04 22:37 ` Thomas Klausner
2014-01-04 22:53 ` Jani Nikula
2014-04-08 11:26 ` David Bremner
[not found] ` <20140408123312.GZ5053@danbala.tuwien.ac.at>
2014-06-26 12:02 ` David Bremner
2014-06-26 12:52 ` David Bremner
2014-06-26 13:08 ` notmuch-0.18 issues [was Re: notmuch-0.16: realpath() compatibility issue; clang visibility problem] Thomas Klausner
2014-06-26 13:16 ` Tomi Ollila
2014-06-26 15:00 ` David Bremner
2017-03-12 16:21 ` David Bremner
2017-03-12 17:24 ` Tomi Ollila
2017-03-12 20:52 ` Thomas Klausner
2017-03-12 16:00 ` notmuch-0.16: realpath() compatibility issue; clang visibility problem David Bremner
Code repositories for project(s) associated with this public inbox
https://yhetil.org/notmuch.git/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).