Re: build failures on Mac OS X 10.6.8 - diagnosis

[Tomi Ollila <tomi.ollila@iki.fi>]

On Tue, Jun 02 2015, Nate Eagleson <nate@nateeag.com> 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