Re: [PATCH 3/4] ruby: Add workarounds to use in-tree build not the installed one

Subject: Re: [PATCH 3/4] ruby: Add workarounds to use in-tree build not the installed one

Date: Thu, 24 May 2012 00:02:28 +0200

To: Ali Polatel

Cc: David Bremner, notmuch@notmuchmail.org

From: Felipe Contreras


On Mon, May 7, 2012 at 5:02 PM, Ali Polatel <alip@exherbo.org> wrote:
> - Make mkmf use the notmuch.h under ../../lib
> - Use libnotmuch.a instead of linking to the installed libnotmuch.so

How has this ever worked?

libnotmuch.so links to many things, fortunately when linking Ruby's
notmuch.so binding to libnotmuch.so.3 all those dependencies are
resolved for us, but when you link to libnotmuch.a you need notmuch.so
to link against all those dependencies.

This is triggering cryptic errors such as:

/usr/lib/ruby/1.9.1/rubygems/custom_require.rb:36:in `require':
foo/notmuch.so: undefined symbol:
_ZTVN10__cxxabiv117__class_type_infoE - foo/notmuch.so (LoadError)

Presumably because not even libstdc++.so is linked.

I don't see how this patch could be fixed properly easily, and it was
labeled as a hack, and I didn't like it in the first place anyway, so
I'm going to revert it by tomorrow if I don't hear any good reason not
to.

I also suggest making a brown-paper-bag release 0.13.1 because 0.13
has completely unusable Ruby bindings; there's just no way to compile
them and make them work.

Cheers.

-- 
Felipe Contreras

Thread: