[Top][All Lists]

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

Re: LT_* equivalent to AC_CHECK_LIB?

From: Tim Mooney
Subject: Re: LT_* equivalent to AC_CHECK_LIB?
Date: Mon, 3 Jul 2006 15:42:13 -0500 (CDT)

In regard to: Re: LT_* equivalent to AC_CHECK_LIB?, Albert Chin said (at...:

The specific case I'm looking at is for a package that wants to
check for libneon.  Neon (which is a libtool library) might have
been linked against OpenSSL (which might require pthread libraries
and/or krb5 libraries), and definitely requires one of libxml2
(which might have requirements like zlib, pthread, libm, et. al.) or
expat.  If I want to check for libneon at configure time, using just
AC_CHECK_LIB or AC_SEARCH_LIB will be extremely painful, because
even with the fourth argument to either of those macros, I'll still
have to write a battery of configure tests to figure out which
particular combination of libraries is required to get libneon and
its dependencies.  If there's a libtool-aware equivalent macro, it
would be so much easier.

Is libneon a static library? If not, and libneon has the 3rd-party
libraries as dependencies, why shouldn't linking with just -lneon

It is static.  The default for libneon is to build static only, so on
many systems where the main package would be configured, there would only
be a static libneon available.

You would certainly know better than I, but I was also under the
impression that not all of the common UNIX variants automatically pull
in dependant libraries, even when they're listed as dependencies for
a shared libneon.  I know that works on many (Linux and most/all?
ELF-based systems) systems, but I thought a few of the platforms

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]