Re: LT_* equivalent to AC_CHECK_LIB?

[Tim Mooney]

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
> work?

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
didn't.

Tim
--
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