notmuch-0.16: realpath() compatibility issue; clang visibility problem

classic Classic list List threaded Threaded
20 messages Options
Thomas Klausner Thomas Klausner
Reply | Threaded
Open this post in threaded view
|

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

_______________________________________________
notmuch mailing list
[hidden email]
http://notmuchmail.org/mailman/listinfo/notmuch

patch-notmuch-config.c (1K) Download Attachment
patch-lib_notmuch-private.h (361 bytes) Download Attachment
Jani Nikula Jani Nikula
Reply | Threaded
Open this post in threaded view
|

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" <[hidden email]> 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
> [hidden email]
> http://notmuchmail.org/mailman/listinfo/notmuch
>


_______________________________________________
notmuch mailing list
[hidden email]
http://notmuchmail.org/mailman/listinfo/notmuch
Jani Nikula Jani Nikula
Reply | Threaded
Open this post in threaded view
|

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" <[hidden email]> wrote:
>
> For the visibility issue please upgrade Notmuch.
>
> BR,
> Jani.
>
> On Jan 4, 2014 2:26 PM, "Thomas Klausner" <[hidden email]> 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
> > [hidden email]
> > http://notmuchmail.org/mailman/listinfo/notmuch
> >


_______________________________________________
notmuch mailing list
[hidden email]
http://notmuchmail.org/mailman/listinfo/notmuch
Thomas Klausner Thomas Klausner
Reply | Threaded
Open this post in threaded view
|

Re: notmuch-0.16: realpath() compatibility issue; clang visibility problem

In reply to this post by Jani Nikula
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
[hidden email]
http://notmuchmail.org/mailman/listinfo/notmuch
Thomas Klausner Thomas Klausner
Reply | Threaded
Open this post in threaded view
|

Re: notmuch-0.16: realpath() compatibility issue; clang visibility problem

In reply to this post by Jani Nikula
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
[hidden email]
http://notmuchmail.org/mailman/listinfo/notmuch
Tomi Ollila-2 Tomi Ollila-2
Reply | Threaded
Open this post in threaded view
|

Re: notmuch-0.16: realpath() compatibility issue; clang visibility problem

On Sat, Jan 04 2014, Thomas Klausner <[hidden email]> 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
[hidden email]
http://notmuchmail.org/mailman/listinfo/notmuch
David Bremner-2 David Bremner-2
Reply | Threaded
Open this post in threaded view
|

Re: notmuch-0.16: realpath() compatibility issue; clang visibility problem

In reply to this post by Thomas Klausner
Thomas Klausner <[hidden email]> 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
[hidden email]
http://notmuchmail.org/mailman/listinfo/notmuch
Thomas Klausner Thomas Klausner
Reply | Threaded
Open this post in threaded view
|

Re: notmuch-0.16: realpath() compatibility issue; clang visibility problem

In reply to this post by Tomi Ollila-2
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
[hidden email]
http://notmuchmail.org/mailman/listinfo/notmuch
Thomas Klausner Thomas Klausner
Reply | Threaded
Open this post in threaded view
|

Re: notmuch-0.16: realpath() compatibility issue; clang visibility problem

In reply to this post by David Bremner-2
On Sat, Jan 04, 2014 at 09:18:15AM -0400, David Bremner wrote:
> Thomas Klausner <[hidden email]> 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
[hidden email]
http://notmuchmail.org/mailman/listinfo/notmuch
Jani Nikula Jani Nikula
Reply | Threaded
Open this post in threaded view
|

Re: notmuch-0.16: realpath() compatibility issue; clang visibility problem


On Jan 5, 2014 12:38 AM, "Thomas Klausner" <[hidden email]> 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
[hidden email]
http://notmuchmail.org/mailman/listinfo/notmuch
David Bremner-2 David Bremner-2
Reply | Threaded
Open this post in threaded view
|

Re: notmuch-0.16: realpath() compatibility issue; clang visibility problem

In reply to this post by Thomas Klausner
Thomas Klausner <[hidden email]> 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
[hidden email]
http://notmuchmail.org/mailman/listinfo/notmuch
David Bremner-2 David Bremner-2
Reply | Threaded
Open this post in threaded view
|

Re: notmuch-0.16: realpath() compatibility issue; clang visibility problem

Thomas Klausner <[hidden email]> 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
[hidden email]
http://notmuchmail.org/mailman/listinfo/notmuch
David Bremner-2 David Bremner-2
Reply | Threaded
Open this post in threaded view
|

Re: notmuch-0.16: realpath() compatibility issue; clang visibility problem

David Bremner <[hidden email]> 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
[hidden email]
http://notmuchmail.org/mailman/listinfo/notmuch
Thomas Klausner Thomas Klausner
Reply | Threaded
Open this post in threaded view
|

notmuch-0.18 issues [was Re: notmuch-0.16: realpath() compatibility issue; clang visibility problem]

In reply to this post by David Bremner-2
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
_______________________________________________
notmuch mailing list
[hidden email]
http://notmuchmail.org/mailman/listinfo/notmuch

patch-doc_Makefile.local (538 bytes) Download Attachment
patch-doc_prerst2man.py (357 bytes) Download Attachment
patch-emacs_Makefile.local (370 bytes) Download Attachment
patch-configure (378 bytes) Download Attachment
Tomi Ollila-2 Tomi Ollila-2
Reply | Threaded
Open this post in threaded view
|

Re: notmuch-0.18 issues [was Re: notmuch-0.16: realpath() compatibility issue; clang visibility problem]

On Thu, Jun 26 2014, Thomas Klausner <[hidden email]> 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
[hidden email]
http://notmuchmail.org/mailman/listinfo/notmuch
David Bremner-2 David Bremner-2
Reply | Threaded
Open this post in threaded view
|

Re: notmuch-0.18 issues [was Re: notmuch-0.16: realpath() compatibility issue; clang visibility problem]

In reply to this post by Thomas Klausner
Thomas Klausner <[hidden email]> 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
[hidden email]
http://notmuchmail.org/mailman/listinfo/notmuch
David Bremner-2 David Bremner-2
Reply | Threaded
Open this post in threaded view
|

Re: notmuch-0.16: realpath() compatibility issue; clang visibility problem

In reply to this post by Thomas Klausner
Thomas Klausner <[hidden email]> 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
[hidden email]
https://notmuchmail.org/mailman/listinfo/notmuch
David Bremner-2 David Bremner-2
Reply | Threaded
Open this post in threaded view
|

Re: notmuch-0.18 issues [was Re: notmuch-0.16: realpath() compatibility issue; clang visibility problem]

In reply to this post by Thomas Klausner
Thomas Klausner <[hidden email]> 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
[hidden email]
https://notmuchmail.org/mailman/listinfo/notmuch
Tomi Ollila-2 Tomi Ollila-2
Reply | Threaded
Open this post in threaded view
|

Re: notmuch-0.18 issues [was Re: notmuch-0.16: realpath() compatibility issue; clang visibility problem]

On Sun, Mar 12 2017, David Bremner <[hidden email]> wrote:

> Thomas Klausner <[hidden email]> 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
[hidden email]
https://notmuchmail.org/mailman/listinfo/notmuch
Thomas Klausner Thomas Klausner
Reply | Threaded
Open this post in threaded view
|

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 <[hidden email]> wrote:
>
> > Thomas Klausner <[hidden email]> 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
[hidden email]
https://notmuchmail.org/mailman/listinfo/notmuch