Re: Git configure/make does not honor ARFLAGS
- From
Eric Sunshine <sunshine@sunshineco.com>
- Date
- Sep 13, 2015, 17:11 UTC
- Message-ID
- <CAPig+cQV-kaDDdBH+QZXsSjDHjP2CUYDXp3WKSBtgguVmLvofg@mail.gmail.com>
- In-Reply-To
- <20150913101727.GB26562@sigill.intra.peff.net>
On Sun, Sep 13, 2015 at 6:17 AM, Jeff King <peff@peff.net> wrote:
Show 15 quoted lines
> 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.
Show 12 quoted lines
>> The Makefile might benefit from the following for users who need to >> tweak things: >> >> ARFLAGS ?= rcs >> ... >> >> $(QUIET_AR)$(RM) $@ && $(AR) $(ARFLAGS) $@ $^ >> ... > > Yeah, that does sound reasonable (even if one does not set $(AR) to > something completely different, they might need slightly different > flags).