On Tuesday, January 03, 2012 09:08:32 PM Bruno Haible wrote:
> Daniel Schepler wrote:
> > First of all, if I try running gnulib-tool --import --lgpl=2 glob, it
> > reports the license of opendir, readdir, closedir modules is
> > incompatible. (I guess because their files report "LGPL" as the license
> > instead of "LGPLv2+".)
>
> Yes, we prefer the LGPLv3+ license over LGPLv2+ nowadays, due to
> the several advantages of this newer license. If you can use code
> under LGPLv3+ instead of LGPLv2, just pass the option --lgpl to
> gnulib-tool.
OK, now I feel silly. I thought for sure I'd tried --lgpl or --lgpl=3, but I
guess not.
>
> > Then, if I add --avoid to leave out those
> > modules which shouldn't be needed on Windows anyway, I run into problems
>
> Nope, you're misunderstanding the situation. The modules
> opendir, readdir, closedir *are* needed on Windows with MSVC.
> See the files gnulib/doc/posix-functions/*dir.texi for details.
>
> > trying to run "./configure CC=cl CXX=cl" with for example string.h
> > containing a line
> >
> > #include ""
> >
> > where the template shows it should be generating a #include_next
> > line.
>
> The parameters to configure are not right. For using MSVC with
> autoconf-generated configure scripts,
> 1) Set the environment variables PATH, INCLUDE, LIB to work
> with your installation.
> 2) Install the programs 'compile' and 'ar-lib' from gnulib/build-aux/.
> They are not copied automatically, but are rather considered part
> of the build environment.
> 3) Use a configuration statement like this:
>
> # The _WIN32_WINNT setting is needed so that the header files make only
> # those functions visible that are present in the specified Windows
> version, # not also those present in newer Windows versions. Cf.
> # "Modifying WINVER and _WIN32_WINNT"
> # <http://msdn.microsoft.com/en-us/library/6sehtctf.aspx>
> # and "Using the Windows Headers"
> # <http://msdn.microsoft.com/en-us/library/aa383745%28v=vs.85%29.aspx>
> # With _WIN32_WINNT_VISTA or newer, is not self-contained.
> #
> # CFLAGS="-MD" leads to problems, e.g. in _get_osfhandle call
> #
> win32_target=_WIN32_WINNT_WINXP # 0x0501
> ./configure --host=i586-pc-mingw32 --prefix=/usr/local/msvc \
> CC="$HOME/msvc/compile cl -nologo" \
> CFLAGS="" \
> CXX="$HOME/msvc/compile cl -nologo" \
> CXXFLAGS="" \
> CPPFLAGS="-D_WIN32_WINNT=$win32_target
> -I/usr/local/msvc/include" \
> LDFLAGS="-L/usr/local/msvc/lib" \
> LD="link" \
> NM="dumpbin -symbols" \
> STRIP=":" \
> AR="$HOME/msvc/ar-lib lib" \
> RANLIB=":"
OK, thanks for the pointers. Is this documented somewhere in gnulib or
perhaps in autoconf/automake? (I certainly don't see it in the template
INSTALL file generated by automake.)
Btw, should that be --build=i686-w64-mingw32 instead since I'm not cross-
compiling?
> > I also tried
> > making a mingw32 build of the results, which worked fine. But then if I
> > try to link a small sample program using glob, by using the Visual
> > Studio compiler linking against gnulib.lib (a copy of libgnu.a), I get
> > errors with undefined symbols referenced from the library, for example
> > _opendir.
>
> Yes. One of the differences between mingw and MSVC is that the latter
> does not have the functions.
Ah, that would be why I thought the *dir modules were unneeded: my first run
was to do a mingw cross build on Linux before I moved the files over to Windows
to try the MSVC build.
> > So my question is: is there any way to get the glob() function to be
> > available from a Visual Studio compiled program?
>
> Yes, see above.
>
> > (This is related to
> > development of a new feature of a large existing product, and porting
> > the whole thing to be able to use mingw or Cygwin instead of Visual
> > Studio for the Windows version would be more work than just taking out
> > the glob call and writing a manual version. Also, our product doesn't
> > use autoconf at all, so having hard coded include paths in the headers
> > wouldn't work for us.)
>
> Sure. Just take care, when distributing your product, that you fulfil
> the LGPL license. In practice, if the rest of your product is proprietary,
> this means, among other provisions, that you distribute
> - the LGPLed parts as
