build failures on Mac OS X 10.6.8 - diagnosis

build failures on Mac OS X 10.6.8 - diagnosis

[Nate Eagleson]

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?

If not, what would be a better way to solve this?

Thanks.

-Nate

Re: build failures on Mac OS X 10.6.8 - diagnosis

[Tomi Ollila]

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

Re: build failures on Mac OS X 10.6.8 - diagnosis

[J. Lewis Muir]

On 6/3/15 1:00 AM, Tomi Ollila wrote:
> 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

Hi, Tomi.

But isn't it a local library that is only used by Notmuch at compile
time?  It isn't installed anywhere by "make install", right?  So, it
would be easy to change the name, no?  But maybe I'm missing something.

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

I checked Homebrew and MacPorts, and they don't do anything (at least
not in their respective Notmuch packages; it's still possible they do
something globally that I don't know about).

I checked pkgsrc, and they rename the library to libmyutil.a.

Regards,

Lewis

Re: 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@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