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 _______________________________________________ Autoconf mailing list Autoconf@xxxxxxx http://lists.gnu.org/mailman/listinfo/autoconf
