[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: ar(1) issue building coreutils on 64-bit AIX
From: |
Ralf Wildenhues |
Subject: |
Re: ar(1) issue building coreutils on 64-bit AIX |
Date: |
Mon, 20 Aug 2007 23:00:03 +0200 |
User-agent: |
Mutt/1.5.13 (2006-08-11) |
Hello all,
* Peter Rosin wrote on Fri, Aug 17, 2007 at 09:24:39PM CEST:
>
> Just pointing out that for libtool the archiver is never invoked as
> either of:
> $AR $AR_FLAGS cru ...
> $AR $AR_FLAGS x ...
> $AR $AR_FLAGS t ...
> it is always one of these instead:
> $AR $AR_FLAGS ...
> $AR x ...
> $AR t ...
>
> That usage of $AR_FLAGS seems consistent with your description
> of $ARFLAGS in automake.
Ah, so the chance of reconciliation with Automake's ARFLAGS just got a
wee bit better. Except that Automake uses
$(AR) $(ARFLAGS) LIBRARY OBJECTS...
and Libtool would like to not have a space after ${ARFLAGS}, if it wants
to support the w32 LIB program. This, however, would not work with the
$(ARFLAGS) macro in a makefile: it is not portable to assume that 'make'
will honor trailing white space in a macro set in the makefile (besides
the fact that I think it is error-prone): pmake for example does not,
contray to Posix. However, it does honor it on the command line, like:
pmake "ARFLAGS=cru "
So then I thought of ugly hacks like
AC_SUBST([ARFLAGS], ["cru ''"])
but that will then fail when $ARFLAGS is used in scripts like libtool
(could maybe be hacked around?), or
AC_SUBST([ARFLAGS], ["cru \\
"])
but even that will not get pmake to behave. I can get pmake to add a
space with this:
ARFLAGS = cru
ARFLAGS +=
but of course that is not portable either, and I haven't yet found a way
to add one for Solaris 2.6 make.
So pick and choose:
- drop $AR_FLAGS in libtool, instead use ${ARFLAGS} and keep in sync
with Automake's idea of it
- keep $AR_FLAGS and allow for LIB to be used as archiver from within
Libtool.
FWIW, I don't currently see how to easily get Automake to allow LIB as
archiver for *_LIBRARIES.
Cheers,
Ralf