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