Re: Is gnulib supposed to support Visual Studio builds?

[Daniel Schepler]

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
> > <string.h> 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, <winsock2.h> 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 <dirent.h> 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 sources with a Makefile or similar,
>   - your parts as .obj or .lib files,
>   - and a Makefile for linking the two parts together.
> So that users can modify the LGPLed parts of your product.

Well, our product is somewhat unusual in that we distribute source code for 
most of our product already to customers.  Only our simulation kernel is 
distributed as precompiled objects.  So I think what I'll do is:
- lib/gnulib will contain just the MSVC version of the library binary, along 
with the glob.h and glob-libc.h headers, and README and COPYING files.
- check the sources into our Subversion repository under addons/gnulib.  This 
will make it easy to fulfill demands for the gnulib source code as required by 
the LGPL, and also make it easy for internal developers to update or import 
new modules as needed.

That reflects what we already do for zlib -- although I guess zlib's license is 
BSD-style.  On the other hand, the sources take only about 1.6 MB uncompressed 
and 300 KB compressed last I checked, which wouldn't add much to the current 
size.  So maybe it would be easier just to include lib/gnulib/src.

Maybe we should double check whether MacOS X supports glob.  Even though we 
don't officially support Mac anymore, I think some internal developers still 
use 
it.  I'd be surprised if it doesn't support glob, though.
-- 
Daniel Schepler