Hi Andrew,
On 10/23/2009 5:34 PM, Andrew W. Nosenko wrote:
On Fri, Oct 23, 2009 at 00:50, Alfred M. Szmidt<ams@xxxxxxx> wrote:
The way is to simply not use pkg-config, and use AC_CHECK_* functions
to find what is needed; and let the user specify where/what, using
*FLAGS.
Can I ask hard to me and seems easy to you question:
how I can detect using AC_CHECK_* 2nd, 3rd etc libraries, which need
to resolve symbols in 1st layer library? For example, I want to link
libxml2. How I should to obtain LDFLAGS, which would to statisfy
libxml2 link needs? Whether I need to add -lzlib? -lpthread? Or
If your project uses libxml's API, then you as the maintainer should be
very aware of requisite dependencies of that library. The AC_CHECK_LIB
macro accepts a fifth argument, other-libraries, which is a
whitespace-separated list of dependent libraries (actually command-line
options, e.g., [-lzlib -lpthread -lX11]) that are required by the
primary library that you're checking for. Note, however, that if you've
already tested for the presence of any of these 2nd and 3rd level
libraries in previous AC_CHECK_LIB tests, then these references will
already be in the LIBS variable, and thus used in this test automatically.
just -pthread (no library but C compiler flag)? How using AC_CHECK_*
I can guess _preprocessor_ flags? (Hint -D_REENTRANT, IIRC)? How
Preprocessor (CPP) flags are irrelevant, because AC_CHECK_LIB merely
links to the symbol for which you are looking. It doesn't try to execute
the program at all. If the compiler and linker are able to build a
program that references the library symbol, then the check passes.
CPPFLAGS would only matter if the check needed to properly execute code
from the library, which it does not. There is another macro called
AC_RUN_IFELSE, but it's use is discouraged because it assumes about the
environment. Generally, if you can link to a symbol from a library, then
you've accomplished your goal of testing for a symbol from that library.
using the same, or any another check I can guess name of library if
package maintainer changed it for strong for he, but absolutely
unpredictable for me way and reason? (Hint SleepyCat's Berkeley DB
v4.1 has official name libdb-4.1 from author's (sleepycat) point of
view, but FreeBSD port maintaner(s) decided to rename it to libdb41.
How I can to read his minds????? How I can to guess that someone
doesn't like characters '-' and '.' so strong that decide to break
compatibility with upstream????)
Issues like this are the reason why AC_SEARCH_LIBS was invented. Using
AC_SEARCH_LIBS, you can specify a list of library names from most
probable to least probable in the library argument. The system will
attempt to search for the specified symbol in any of those library
names. In general, unless you know the name of a library on a given
system type, you can't link to that library. Thus, part of porting your
application to a given platform is to find out the proper library names
on that platform, and make sure that AC_SEARCH_LIBS contains that name
in it's list of possible candidates for the desired functionality.
And please, don't say about "Linux has interlibrary dependency for
shared libraries". First at all, not all libraries are shared (even
under Linux). Second, Linux is not only one flavor of Unix. Third,
sometime developers are forced to use OS'es different from Unix at
all. And forth, recall the CPPFLAFS!
I don't know of any flavor of Unix that has "interlibrary dependencies"
as you describe them here - at least most people don't use those linker
options. Additionally, most people on this list are not necessarily
pro-Linux, and anti-Solaris/BSD/MacOSX/AIX, and so on. The Autotools
attempts to be Unix-flavor agnostic, which is one of the strengths of
these tools.
Regards,
John
_______________________________________________
Autoconf mailing list
Autoconf@xxxxxxx
http://lists.gnu.org/mailman/listinfo/autoconf
