Re: AC_SEARCH_LIBS and the LIBS variable - cross platform?

[Brian Dessent]

NightStrike wrote:

> Using AC_CHECK_LIB or AC_SEARCH_LIBS will possibly append -lname to
> LIBS where name is the name of the library.  If make is nmake on a
> windows platform, is this ok?  Does nmake require libraries listed in
> that variable to be in the form of "name.lib" instead of "-lname"?
> Does autoconf support this kind of cross-platform library checking?

Simply putting "-lname" into LIBS should be Make-neutral.  Make doesn't
give any special consideration to LIBS or any other variable, it just
invokes the recipes for a target as written without knowledge of their
semantics.  So I don't understand the nature of the question.

GNU Make does have the ability to specify -lname in a prerequisite list
for a target.  In that case it will infer that -lname refers to
libname.a (or some other variation) and use some GNU Make specific
search strategy to find it.  If you're doing that, then yes that's GNU
Make specific and nmake will choke.  But how often do you really write
"foo: foo.c $LIBS" in a Makefile?  That sounds like a very bad idea to
rely on since the search algorithm for resolving -lname is hard coded
into make and seems to vary with the platform make was built for.

And besides being GNU Make specific, using -lname in a prerequisite
lists seems like a bad idea for another reason: what does "-lname"
really mean?  It means two things, first translate -lname into libname.a
or libname.so or libname.dll.a or name.lib or libname.dylib (or a
billion other possible variants.)  It also means to search some
unspecified path list for that filename, and that list can also depend
on a million things: the flags passed to the compiler/linker, built in
search paths in the compiler/linker, environment variables that the
compiler/linker knows about, configuration files that the
compiler/linker reads, etc.  It's just way too vague to write "-lname"
and expect make to know about all that complicated logic.

If you're putting something in a prerequisite list in a Makefile that
implies you know how to rebuild it.  If you know how to rebuild it then
you must have its actual filename somewhere, so just use that in the
prerequisite list.  If instead you know only that you need to link with
"-lname" but you don't know how to remake "libname", i.e. it's some
system or external library, or it's not in the tree of the package being
built, then it doesn't make any sense to list that on a prerequisites
list in a Makefile.  If the reason for putting "-lname" instead of
"path/to/libname.a" in the preprequisites list was because you want to
reuse $^ in the link command or something, then that seems silly because
most all linkers will happily acccept a library specified as a regular
filename.  "-lname" is for when you don't know or care where libname is
actually located, and you want the linker to figure that out.  And,
again, in that situation you wouldn't know how to remake libname anyway,
so why is it in a prerequisite list?

All that aside, if the user is using nmake then this is probably the
least of your worries.  nmake is part of the MS Visual Studio toolchain
and so there's a pretty good chance that if the user is using nmake
they're also using the other MS tools like cl.exe, link.exe, lib.exe,
ml.exe, rc.exe, and so on.  Those tools all have their own command
option syntax that is not like GNU tools.  So really unless the user is
using nmake as a driver for GNU tools then the real issue is not the
flavor of make.

There are several workaround for this.  One is to use wrappers that make
the Visual Studio tools take GNU-like options.  I think there are at
least two such wrapper projects out there, wgcc and something else. 
There are patches pending for libtool that support wgcc.  Another
alternative is a different set of patches for libtool that define a
native target (*winnt*) that invokes the MS tools directly without
wrappers.

Brian