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

[David Bremner <david@tethera.net>]

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