[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: handling of missing AR

From: Tim Mooney
Subject: Re: handling of missing AR
Date: Thu, 30 Mar 2006 00:06:09 -0600 (CST)

In regard to: Re: handling of missing AR, Ralf Wildenhues said (at 7:49am...:

If, however, we know that ar is going to be required but it's not found
at configure time, wouldn't it be better to have configure emit an error
message such as:

But how do you know the user will use libtool to build a library even?
I've heard of people using AC_PROG_LIBTOOL merely to get the path
hardcoding in their programs (for installed third-party packages).
There is currently a suggestion on the Automake lists to support partial
linking more conveniently, including AC_PROG_LIBTOOL to get at "ld -r".
Neither of these uses would need ar.  Or: what about the crazy package
that does not use Automake, invokes AC_PROG_LIBTOOL but uses that to
create its libraries only on a few systems (where it deems their own
shared library creation system much better)?  Yes, I remember to have
seen a similar setup.


These are all good points, and pretty much invalidate my argument.
Considering the (mis)uses that a few people are putting libtool to, it's probably best to leave things as is.

My point is that you simply often can't know whether it will be used
even if you think it will.

That's really the crux of the matter, and since it's not possible to
know whether it's going to be used, having configure error out is just
going to cause new headaches for people.

Here's another way to look at it.  Let's say I'm a package author, and
my calls the appropriate libtool macros.  If libtool's portion
of configure doesn't error out when something that *libtool* needs isn't
available, then doesn't that put the onus back on the package author to
do lots of post-libtool-configure checks to make sure that AR, NM, CC, et.
al. are defined?  Worse yet, the package maintainer now has to be concerned
with what (libtool-specific) options were passed to configure (e.g. if
--disable-shared was specified, then we may not need to worry about LD).
Moreover, the package author may not have any idea what compiler toolchain
commands are needed on some esoteric platform that he or she has never

Right.  I completely agree that you have a point here: it would be
better to have a configure error here for a majority of users.

The real question is, does libtool's configure macro know whether ar is
needed.  You seem to be indicating that it never knows (in any case)
whether ar is needed. Am I understanding that correctly?

I am trying to say that I can imagine good uses of AC_PROG_LIBTOOL even
without --disable-shared that do not involve `ar'.

Here may be an idea to come closer to what you'd like:

It's not even that I liked the idea of it erroring; I'm very experienced
with autoconf and using configure, so I personally don't like macros that
think they're smarter than the person running configure.  What I was
proposing was based on the misguided notion that configure could know if
ar would be needed, and it would be better for the package's maintainer if
the problem was caught early and configure complained loudly.  If someone
that's inexperienced is running configure and they get an obvious error
from configure that they're missing something, they're more likely to be
able to fix it themselves, which lessens the bug report load for the
package's maintainer.

maybe by default
we should fail on missing AR, LD(?), RANLIB(?), NM(??) (increasingly
questionable), and add options to LT_INIT([OPTIONS..]) (which is how CVS
Libtool spells AC_PROG_LIBTOOL) that would allow to override this
failure.  Hmm.  Need to think about this.  That would at least be better
than, say, an interface such as AC_PROG_LIBTOOL([RUN-IF-AR-FAILS],
[RUN-IF-NM-FAILS], ...) with all failure arguments defaulting to `:'.

:-)  I think you've swayed me over to your side now.  It *might* be a
good idea to AC_MSG_WARN if those things aren't found, but I no longer
think it's a good idea to error out.

Tim Mooney                              address@hidden
Information Technology Services         (701) 231-1076 (Voice)
Room 242-J6, IACC Building              (701) 231-8541 (Fax)
North Dakota State University, Fargo, ND 58105-5164

reply via email to

[Prev in Thread] Current Thread [Next in Thread]