On Sun, Sep 13, 2015 at 1:11 PM, Eric Sunshine <sunshine@sunshineco.com> wrote:
Show 31 quoted lines
> On Sun, Sep 13, 2015 at 6:17 AM, Jeff King <peff@peff.net> wrote:
>> On Sun, Aug 30, 2015 at 05:34:59PM -0400, Jeffrey Walton wrote:
>>> I'm working on an old OS X machine. I needed to perform:
>>>
>>> AR=libtool
>>> ARFLAGS="-static -o"
>>> ...
>>> make configure
>>> ./configure ...
>>> make
>>
>> Hrm. Your "$(AR)" is not really "ar" then, is it? It has been a long
>> time since I played with libtool, but what is the reason that you are
>> calling libtool and not "ar" in the first place. Is it that you do not
>> have "ar" at all, and libtool performs some other procedure? If so, is
>> there a more ar-compatible wrapper that can be used?
>
> This isn't GNU's libtool. It's Apple's libtool, an entirely different
> beast, which is an 'ar' replacement and is needed when linking
> Universal binaries containing code for more than one architecture,
> such as 'ppc' and 'i386', so the same executable can run on multiple
> architectures. This tool dates all the way back to at least NextStep
> 3.1 when NeXT ported NextStep to Intel hardware (i486) from NeXT
> computers (m68k). The name "Universal" is an Apple invention, but back
> in the NeXT days, they were called Multi-Architecture Binaries (MAB)
> or, colloquially, just FAT (for "fat"); there was a corresponding
> "lipo" command (short for "liposuction") to "thin" out "fat" binaries.
> NeXT's libtool predates GNU's libtool by a few years: May 1993 vs.
> July 1997, respectively. When an attempt is made to use 'ar' on
> Universal object files, it errors out saying that it can't be used
> with such files and recommends 'libtool' instead.