NightStrike wrote: > All of the information that I've been able to find for nmake defines > that the format of the LIBS variable should be "name.lib" instead of > "-lname". This implies to me, possibly incorrectly, that nmake by > default will pass $(LIBS) to the LINK.EXE command, and that LINK.EXE > interprets libraries in that fashion. Like any make implementation nmake has built in rules. They are documented on MSDN along with everything else: <http://msdn2.microsoft.com/en-us/library/cx06ysxh.aspx>. LIBS is not involved anywhere that I can see. But of course in most real life Makefiles, $LIBS is usually specified on the rule link command line. That means it has to be in the form the linker understands, so the real question is does MSVC link.exe understand -lname (no, it does not), not about nmake or Makefiles. Again, it's all on MSDN so if you want to know how to specify libs to link.exe, look there: <http://msdn2.microsoft.com/en-us/library/hx5b050y.aspx> <http://msdn2.microsoft.com/en-us/library/wk97ab1b.aspx> <http://msdn2.microsoft.com/en-us/library/ba1z7822.aspx> <http://msdn2.microsoft.com/en-us/library/92b5ab4h.aspx> <http://msdn2.microsoft.com/en-us/library/hcce369f.aspx> <http://msdn2.microsoft.com/en-us/library/y0zzbyt4.aspx> > With gcc, if I want to link with a given library, I just put "-lname" > somewhere on the command line. Therefore, the $(LIBS) variable can be > easily used in a makefile. The point I was trying to make earlier is that gcc will certainly accept "-lname" (and doing so tells it to search each dir of the configured list of search locations for libname.dll.a, name.dll.a, libname.a, name.lib, and libname.dll in that order) but you can also just specify the name of the library simply as a filename and gcc will happily use that. E.g. if you know that name.lib is in . then "gcc -o out obj.o name.lib" is functionally equivalent to "gcc -o out obj.o -L. -lname", and I don't see why adding name.lib to LIBS wouldn't work just fine. And in fact this is how the MS linker tends to be used, with the link command as just a series of filenames since it does not have any notion of "-l" or "-L". But do note the following from the docs above about searching the LIB environment variable: > If a path is specified with the library name, LINK looks for > the library in that directory. If no path is specified, LINK > looks first in the directory that LINK is running from, and > then in any directories specified in the LIB environment variable. So roughly, you could make the analogue of: LDFLAGS="-L/location/of/lib $LDFLAGS" LIBS="-lname $LIBS" to export LIB="c:\location\of\lib;$LIB" LIBS="name.lib $LIBS" > I am looking for clarification for how to handle this with MSVC. Does > MSVC accept "-l" as an option to add a library? If not, then I don't > know how to use AC_SEARCH_LIBS in a portable way when the compiler is > set to CL.EXE. AC_SEARCH_LIBS, and most of autoconf, tends to be geared toward compilers and linkers that have a command syntax of traditional unix C compilers, i.e. -c -o -g -I -l -L -R etc. Since the MS tools use very different options you'll probably have to write your own macros if you want to support them. That is why the wrapper scripts are a popular choice, because they mean you can use all the existing m4 macros with the MS tools. > I don't think this is what I'm trying to do. Good. > You are correct that all those tools are in use, however that is > alongside a configure script. They are using configure in conjunction > with MSVC8 and 9. Is this kind of cross-platform flexibility not > supported directly by autoconf? Not really, I'd say. > This implies using libtool. I'm only at the stage where I'd like to The wrappers are separate and independent from libtool, but the target=*winnt* patches are obviously not. > be able to run the "AC_SEARCH_LIBS" macro in a portable way. As far > as I can tell, AC_SEARCH_LIBS tries to use a function first with no > compiler options, then with the -l option for each library given in > the argument list. This is not very flexible if using a compiler that > does not support the -l option. If -l only work with gcc, then this > isn't flexible at all, and I can't use AC_SEARCH_LIBS. The native MS tools and autoconf/automake/libtool are typically not mixed. Usually if a project supports being built with the MS tools they supply a separate config.h that is hard-coded with the necessary defines (and can be hand tweaked by the user if necessary) rather than running any configure tests; and a separate standalone Makefile (e.g. "Makefile.vc6") for use with nmake. The alternative is the wrapper scripts/wrapper compiler driver method, or a lot of hand coding of m4. Brian _______________________________________________ Autoconf mailing list Autoconf@xxxxxxx http://lists.gnu.org/mailman/listinfo/autoconf