Sender: Nathan Eagleson <nate4d@gmail.com>
Subject: Re: build failures on Mac OS X 10.6.8 - diagnosis
Mime-Version: 1.0 (Apple Message framework v1085)
Content-Type: text/plain; charset=us-ascii
From: Nate Eagleson <nate@nateeag.com>
In-Reply-To: <m21thtib56.fsf@guru.guru-group.fi>
Date: Fri, 5 Jun 2015 15:26:11 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <0C7BAABC-5AC3-4D6E-AD5D-2420918588C4@nateeag.com>
References: <7156CF8E-BE69-48C0-ACB8-88C7E68CD4BB@nateeag.com>
 <m21thtib56.fsf@guru.guru-group.fi>
To: Tomi Ollila <tomi.ollila@iki.fi>
Cc: notmuch@notmuchmail.org
Precedence: list


On Jun 3, 2015, at 2:00 AM, Tomi Ollila wrote:

> On Tue, Jun 02 2015, Nate Eagleson <nate@nateeag.com> wrote:
>=20
>> Hi folks,
>>=20
>> 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.
>>=20
>> The failure was reported on this list a few months ago, but no
>> explanation or solution was found:
>>=20
>> http://notmuchmail.org/pipermail/notmuch/2015/020531.html
>>=20
>> 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.
>>=20
>> That list includes `/usr/lib/libutil.dylib`, but not notmuch's =
built-in
>> `util/libutil.a`.
>>=20
>> I have not found a sane way to tell 10.6.8's ld to prefer libutil.a =
over
>> libutil.dylib.
>>=20
>> 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.
>>=20
>> Instead, people are recommending absolute paths when you need to link =
an
>> archive file in preference to existing dylibs:
>>=20
>> =
http://lists.apple.com/archives/darwin-development/2003/Sep/msg00008.html
>> http://stackoverflow.com/questions/844819/how-to-static-link-on-os-x
>>=20
>> As a simple test, I hardcoded an absolute path to libutil in
>> FINAL_NOTMUCH_LDFLAGS, and the compile succeeded.
>>=20
>> 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.
>>=20
>> Does this sound like a sane solution? Would a patch to do this be
>> accepted?
>=20
> 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...
>=20
> ... I think it is somewhat unfortunate (or confusing) to have the =
library
> named as such, and perhaps better naming should have been used, but =
(*)
>=20
> (*) http://martinfowler.com/bliki/TwoHardThings.html

Yep, that all makes sense. ...especially the naming quandary.

>> If not, what would be a better way to solve this?
>=20
> Actually you could check how homebrew etc. solve this problem (or if =
there
> is any) to come with other ideas...

My little research project started when I ran `brew install notmuch` and =
got this
failure. If there is a better solution, the homebrew folks don't have =
it.

so, rename the local library, or use an absolute path to it during =
builds?

The latter feels slightly more robust to me, since it completely =
precludes name collisions.=20
Though if we add 'notmuch' to the lib name, name collisions seem pretty =
unlikely.

If no one else adds any comments in the next day or two, I'll submit a =
patch adding the absolute path behavior.

-Nate