Re: pkg-config wisdom

[John Calcote]

Hi Andrew,

On 10/23/2009 5:34 PM, Andrew W. Nosenko wrote:
> On Fri, Oct 23, 2009 at 00:50, Alfred M. Szmidt<address@hidden>  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