Re: build failures on Mac OS X 10.6.8 - diagnosis
authorNate Eagleson <nate@nateeag.com>
Fri, 5 Jun 2015 19:26:11 +0000 (15:26 +2000)
committerW. Trevor King <wking@tremily.us>
Sat, 20 Aug 2016 21:48:58 +0000 (14:48 -0700)
cc/62f9d8913cb816c72a884959fda2b4da624bca [new file with mode: 0644]

diff --git a/cc/62f9d8913cb816c72a884959fda2b4da624bca b/cc/62f9d8913cb816c72a884959fda2b4da624bca
new file mode 100644 (file)
index 0000000..322e650
--- /dev/null
@@ -0,0 +1,161 @@
+Return-Path: <nate4d@gmail.com>\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 BE0DD6DE17AA\r
+ for <notmuch@notmuchmail.org>; Fri,  5 Jun 2015 12:26:22 -0700 (PDT)\r
+X-Virus-Scanned: Debian amavisd-new at cworth.org\r
+X-Spam-Flag: NO\r
+X-Spam-Score: -0.39\r
+X-Spam-Level: \r
+X-Spam-Status: No, score=-0.39 tagged_above=-999 required=5 tests=[AWL=0.310, \r
+ DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001,\r
+ RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01,\r
+ RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001,\r
+ T_FREEMAIL_FORGED_FROMDOMAIN=0.01,\r
+ T_HEADER_FROM_DIFFERENT_DOMAINS=0.01] 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 Z0fmDocnZIqY for <notmuch@notmuchmail.org>;\r
+ Fri,  5 Jun 2015 12:26:20 -0700 (PDT)\r
+Received: from mail-qc0-f181.google.com (mail-qc0-f181.google.com\r
+ [209.85.216.181])\r
+ by arlo.cworth.org (Postfix) with ESMTPS id 172626DE1733\r
+ for <notmuch@notmuchmail.org>; Fri,  5 Jun 2015 12:26:20 -0700 (PDT)\r
+Received: by qczw4 with SMTP id w4so33601742qcz.2\r
+ for <notmuch@notmuchmail.org>; Fri, 05 Jun 2015 12:26:19 -0700 (PDT)\r
+DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;\r
+ h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc\r
+ :content-transfer-encoding:message-id:references:to;\r
+ bh=R5CmlM0BUcfN18T4nbLDyBOVMajlcecFvvYis9SGaQg=;\r
+ b=ZK20pjukiEs3FzEs2YOmhabMr/8bi8rJEva9+dnPxR/gMJGg/6D8gdyr6lKK3yHGye\r
+ QyyRFajSKl6ON8HvdQlxKKipyyn5wcazkmurGyfFJita9b5nek6GU80begMfuXSZjYPn\r
+ kzT9ebIO2v07eZHsVfyXW3ZYvWysGccTPVFGoKcMd5QXqAY6SneuZ8YBzVtJMAJCzo26\r
+ kis+BgshH1WWZWn1JFuCNdBNI7145b5qkTWEr0fp3gv3EcxMYr3h1ak4955Mvt5qYhIA\r
+ NiW1lIgOpsdwW8fhqStliEx7RMPFfkmrONWLdhmyyXme+lfK6qwjKhJx753E4pTBW41P\r
+ ucpA==\r
+X-Received: by 10.229.211.131 with SMTP id go3mr6231256qcb.18.1433532377973;\r
+ Fri, 05 Jun 2015 12:26:17 -0700 (PDT)\r
+Received: from [10.46.105.28] ([70.42.157.61])\r
+ by mx.google.com with ESMTPSA id k71sm4363746qhc.42.2015.06.05.12.26.15\r
+ (version=TLSv1 cipher=RC4-SHA bits=128/128);\r
+ Fri, 05 Jun 2015 12:26:16 -0700 (PDT)\r
+Sender: Nathan Eagleson <nate4d@gmail.com>\r
+Subject: Re: build failures on Mac OS X 10.6.8 - diagnosis\r
+Mime-Version: 1.0 (Apple Message framework v1085)\r
+Content-Type: text/plain; charset=us-ascii\r
+From: Nate Eagleson <nate@nateeag.com>\r
+In-Reply-To: <m21thtib56.fsf@guru.guru-group.fi>\r
+Date: Fri, 5 Jun 2015 15:26:11 -0400\r
+Content-Transfer-Encoding: quoted-printable\r
+Message-Id: <0C7BAABC-5AC3-4D6E-AD5D-2420918588C4@nateeag.com>\r
+References: <7156CF8E-BE69-48C0-ACB8-88C7E68CD4BB@nateeag.com>\r
+ <m21thtib56.fsf@guru.guru-group.fi>\r
+To: Tomi Ollila <tomi.ollila@iki.fi>\r
+X-Mailer: Apple Mail (2.1085)\r
+Cc: notmuch@notmuchmail.org\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: Fri, 05 Jun 2015 19:26:22 -0000\r
+\r
+\r
+On Jun 3, 2015, at 2:00 AM, Tomi Ollila wrote:\r
+\r
+> On Tue, Jun 02 2015, Nate Eagleson <nate@nateeag.com> wrote:\r
+>=20\r
+>> Hi folks,\r
+>>=20\r
+>> I'm trying to move from Apple's Mail.app in favor of =\r
+offlineimap/notmuch,\r
+>> but I've run into a build failure on Mac OS X 10.6.8.\r
+>>=20\r
+>> The failure was reported on this list a few months ago, but no\r
+>> explanation or solution was found:\r
+>>=20\r
+>> http://notmuchmail.org/pipermail/notmuch/2015/020531.html\r
+>>=20\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 =\r
+being\r
+>> linked in the failed compile.\r
+>>=20\r
+>> That list includes `/usr/lib/libutil.dylib`, but not notmuch's =\r
+built-in\r
+>> `util/libutil.a`.\r
+>>=20\r
+>> I have not found a sane way to tell 10.6.8's ld to prefer libutil.a =\r
+over\r
+>> libutil.dylib.\r
+>>=20\r
+>> My first thought was that there should be an option to prefer =\r
+archives over\r
+>> dylibs, but that does not seem to exist in 10.6.8's version of ld.\r
+>>=20\r
+>> Instead, people are recommending absolute paths when you need to link =\r
+an\r
+>> archive file in preference to existing dylibs:\r
+>>=20\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
+>>=20\r
+>> As a simple test, I hardcoded an absolute path to libutil in\r
+>> FINAL_NOTMUCH_LDFLAGS, and the compile succeeded.\r
+>>=20\r
+>> So, it seems like getting the path to the Makefile's parent directory =\r
+and\r
+>> using it to specify an absolute path to libutil.a would address this\r
+>> issue without introducing new ones.\r
+>>=20\r
+>> Does this sound like a sane solution? Would a patch to do this be\r
+>> accepted?\r
+>=20\r
+> Now that I look at this, I think that having full path to =\r
+util/libutil.a\r
+> should be used (everywhere) and if there is need to use =\r
+*system-provided*\r
+> libutil, then -lutil is to be added to the command line...\r
+>=20\r
+> ... I think it is somewhat unfortunate (or confusing) to have the =\r
+library\r
+> named as such, and perhaps better naming should have been used, but =\r
+(*)\r
+>=20\r
+> (*) http://martinfowler.com/bliki/TwoHardThings.html\r
+\r
+Yep, that all makes sense. ...especially the naming quandary.\r
+\r
+>> If not, what would be a better way to solve this?\r
+>=20\r
+> Actually you could check how homebrew etc. solve this problem (or if =\r
+there\r
+> is any) to come with other ideas...\r
+\r
+My little research project started when I ran `brew install notmuch` and =\r
+got this\r
+failure. If there is a better solution, the homebrew folks don't have =\r
+it.\r
+\r
+so, rename the local library, or use an absolute path to it during =\r
+builds?\r
+\r
+The latter feels slightly more robust to me, since it completely =\r
+precludes name collisions.=20\r
+Though if we add 'notmuch' to the lib name, name collisions seem pretty =\r
+unlikely.\r
+\r
+If no one else adds any comments in the next day or two, I'll submit a =\r
+patch adding the absolute path behavior.\r
+\r
+-Nate\r
+\r