--- /dev/null
+Return-Path: <tomi.ollila@iki.fi>\r
+X-Original-To: notmuch@notmuchmail.org\r
+Delivered-To: notmuch@notmuchmail.org\r
+Received: from localhost (localhost [127.0.0.1])\r
+ by arlo.cworth.org (Postfix) with ESMTP id 8752E6DE13A3\r
+ for <notmuch@notmuchmail.org>; Tue, 2 Jun 2015 23:01:21 -0700 (PDT)\r
+X-Virus-Scanned: Debian amavisd-new at cworth.org\r
+X-Spam-Flag: NO\r
+X-Spam-Score: 1.007\r
+X-Spam-Level: *\r
+X-Spam-Status: No, score=1.007 tagged_above=-999 required=5 tests=[AWL=0.355, \r
+ SPF_NEUTRAL=0.652] autolearn=disabled\r
+Received: from arlo.cworth.org ([127.0.0.1])\r
+ by localhost (arlo.cworth.org [127.0.0.1]) (amavisd-new, port 10024)\r
+ with ESMTP id f_hGqRO79uam for <notmuch@notmuchmail.org>;\r
+ Tue, 2 Jun 2015 23:01:18 -0700 (PDT)\r
+Received: from guru.guru-group.fi (guru.guru-group.fi [46.183.73.34])\r
+ by arlo.cworth.org (Postfix) with ESMTP id E0DAD6DE138F\r
+ for <notmuch@notmuchmail.org>; Tue, 2 Jun 2015 23:01:17 -0700 (PDT)\r
+Received: from guru.guru-group.fi (localhost [IPv6:::1])\r
+ by guru.guru-group.fi (Postfix) with ESMTP id 9FE4810008E;\r
+ Wed, 3 Jun 2015 09:00:53 +0300 (EEST)\r
+From: Tomi Ollila <tomi.ollila@iki.fi>\r
+To: Nate Eagleson <nate@nateeag.com>, notmuch@notmuchmail.org\r
+Subject: Re: build failures on Mac OS X 10.6.8 - diagnosis\r
+In-Reply-To: <7156CF8E-BE69-48C0-ACB8-88C7E68CD4BB@nateeag.com>\r
+References: <7156CF8E-BE69-48C0-ACB8-88C7E68CD4BB@nateeag.com>\r
+User-Agent: Notmuch/0.20+12~gf3d9440 (http://notmuchmail.org) Emacs/24.3.1\r
+ (x86_64-unknown-linux-gnu)\r
+X-Face: HhBM'cA~<r"^Xv\KRN0P{vn'Y"Kd;zg_y3S[4)KSN~s?O\"QPoL\r
+ $[Xv_BD:i/F$WiEWax}R(MPS`^UaptOGD`*/=@\1lKoVa9tnrg0TW?"r7aRtgk[F\r
+ !)g;OY^,BjTbr)Np:%c_o'jj,Z\r
+Date: Wed, 03 Jun 2015 09:00:53 +0300\r
+Message-ID: <m21thtib56.fsf@guru.guru-group.fi>\r
+MIME-Version: 1.0\r
+Content-Type: text/plain\r
+X-BeenThere: notmuch@notmuchmail.org\r
+X-Mailman-Version: 2.1.18\r
+Precedence: list\r
+List-Id: "Use and development of the notmuch mail system."\r
+ <notmuch.notmuchmail.org>\r
+List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
+ <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
+List-Archive: <http://notmuchmail.org/pipermail/notmuch/>\r
+List-Post: <mailto:notmuch@notmuchmail.org>\r
+List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
+List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
+ <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
+X-List-Received-Date: Wed, 03 Jun 2015 06:01:21 -0000\r
+\r
+On Tue, Jun 02 2015, Nate Eagleson <nate@nateeag.com> wrote:\r
+\r
+> Hi folks,\r
+>\r
+> I'm trying to move from Apple's Mail.app in favor of offlineimap/notmuch,\r
+> but I've run into a build failure on Mac OS X 10.6.8.\r
+>\r
+> The failure was reported on this list a few months ago, but no\r
+> explanation or solution was found:\r
+>\r
+> http://notmuchmail.org/pipermail/notmuch/2015/020531.html\r
+>\r
+> By appending `-Wl,-t` to `FINAL_NOTMUCH_LDFLAGS` in Makefile.local, I\r
+> got 10.6.8's ld to dump the list of archives and dylibs that are being\r
+> linked in the failed compile.\r
+>\r
+> That list includes `/usr/lib/libutil.dylib`, but not notmuch's built-in\r
+> `util/libutil.a`.\r
+>\r
+> I have not found a sane way to tell 10.6.8's ld to prefer libutil.a over\r
+> libutil.dylib.\r
+>\r
+> My first thought was that there should be an option to prefer archives over\r
+> dylibs, but that does not seem to exist in 10.6.8's version of ld.\r
+>\r
+> Instead, people are recommending absolute paths when you need to link an\r
+> archive file in preference to existing dylibs:\r
+>\r
+> http://lists.apple.com/archives/darwin-development/2003/Sep/msg00008.html\r
+> http://stackoverflow.com/questions/844819/how-to-static-link-on-os-x\r
+>\r
+> As a simple test, I hardcoded an absolute path to libutil in\r
+> FINAL_NOTMUCH_LDFLAGS, and the compile succeeded.\r
+>\r
+> So, it seems like getting the path to the Makefile's parent directory and\r
+> using it to specify an absolute path to libutil.a would address this\r
+> issue without introducing new ones.\r
+>\r
+> Does this sound like a sane solution? Would a patch to do this be\r
+> accepted?\r
+\r
+Now that I look at this, I think that having full path to util/libutil.a\r
+should be used (everywhere) and if there is need to use *system-provided*\r
+libutil, then -lutil is to be added to the command line...\r
+\r
+... I think it is somewhat unfortunate (or confusing) to have the library\r
+named as such, and perhaps better naming should have been used, but (*)\r
+\r
+(*) http://martinfowler.com/bliki/TwoHardThings.html\r
+\r
+> If not, what would be a better way to solve this?\r
+\r
+Actually you could check how homebrew etc. solve this problem (or if there\r
+is any) to come with other ideas...\r
+\r
+Tomi\r
+\r
+>\r
+> Thanks.\r
+>\r
+> -Nate\r
+\r