build failures on Mac OS X 10.6.8 - diagnosis

[Nate Eagleson]

On Jun 3, 2015, at 2:00 AM, Tomi Ollila wrote:

> On Tue, Jun 02 2015, Nate Eagleson <nate at 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

Yep, that all makes sense. ...especially the naming quandary.

>> 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...

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. 
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