On 3/11/08, Brian Dessent <brian@xxxxxxxxxxx> wrote: > 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. 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. 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. 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. > GNU Make does have the ability to specify -lname in a prerequisite list I don't think this is what I'm trying to do. > 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. 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? > 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. This implies using libtool. I'm only at the stage where I'd like to 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. _______________________________________________ Autoconf mailing list Autoconf@xxxxxxx http://lists.gnu.org/mailman/listinfo/autoconf
