We need to use our own gmime 2.6

[yeled]

as Homebrew has moved onto 3.0.0 and the interaction between that, notmuch rolling their own and this needs fixing - until gmime 3.0 support is complete

[cpiro]

Oh boy. I built with your patch, and still got the same segfault. That new astroid binary definitely used our new gmime shared lib:

$ otool -L $(which astroid) | grep gmime
        /usr/local/Cellar/astroid/0.9.1/gmime/lib/libgmime-2.6.0.dylib (...)

but it also loaded libnotmuch, which was built assuming it would be loaded with its own libgmime. Indeed in the backtrace you can see libnotmuch calling into the foreign libgmime:

Thread 5 Crashed:
0   libgmime-2.6.0.dylib            0x000000010691ae41 decode_addrspec + 443
1   libgmime-2.6.0.dylib            0x000000010691a41e decode_address + 870
2   libgmime-2.6.0.dylib            0x000000010691a013 internet_address_list_parse_string + 73
3   libnotmuch.4.dylib              0x00000001032f3cee _notmuch_thread_create + 832
4   libnotmuch.4.dylib              0x00000001032f17f1 notmuch_threads_get + 63
5   astroid                         0x0000000102dc3c4b Astroid::QueryLoader::loader() + 461
...

I poured the newest notmuch bottle, so those two libgmimes weren't even built with the same toolchain. Also (maybe significantly) I needed to add --disable-mono to get gmime to build. The good news is that by using notmuch's own gmime and not building our own, everything works:

ENV.append_path "PKG_CONFIG_PATH", "/usr/local/opt/notmuch/gmime/lib/pkgconfig"

That's also the bad news – we shouldn't count on the particulars of notmuch's formula and how it satisfies its gmime dependency.

I'm not sure what the answer here is. I was debugging this issue the other day tried to solve it by adding a gmime@2.6.23 to our tap. I really didn't want to add another dependency to the tap, and adding notmuch seems super wrong. I also have no idea how libgmime and macOS's dynamic library system work – whether notmuch and astroid need to call into the same libgmime or not, and if not, whether we could trick dyld to loading them both without renaming one, whether statically linking libgmime to astroid would help, whether we could reliably build our libgmime in such a way that notmuch could call into it . . . I'll keep playing around.

I suppose the easy fix is my good news above, but it seems like kicking the can down the road.

[yeled]

Thanks for all your investigation!

I did try the ENV.append_path "PKG_CONFIG_PATH" method at first but I thought - maybe wrongly - that if we used theirs, it would end up with a worse situation of them changing their build system underneath us could create more future breakages.

What is interesting here is why does my patch work for me and not for you?

21:25 YELP-CHARLIE~[local@2.7.13] % otool -L $(which astroid)|grep gmime                                                          (gmail_keybindings|●1✚1…)
        /usr/local/opt/gmime/lib/libgmime-2.6.0.dylib (compatibility version 624.0.0, current version 624.0.0)

doh. I had not reverted my brew switch gmime 2.6.3 back before building.

Nice catch. OK let's go with your ENV.append until we someone can put effort into porting to gmime 3.

[gauteh]

Looks good, I don't think it is a problem to be tied to notmuches gmime, we'll be pretty close to notmuch anyway.

I hope to be able to mirror notmuches deprecation handling when we port to gmime 3.

• Gaute