Re: AC_SEARCH_LIBS and the LIBS variable - cross platform?

[Brian Dessent]

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