Re: Is gnulib supposed to support Visual Studio builds?

[Bruno Haible]

Hi,

Daniel Schepler wrote:
> I'm trying to use gnulib sources in order to be able to use glob
> internally in the Windows build of our product (i.e. I call
>   std::string pattern = productHome + "/libraries/*/config/*.xml";
>   glob(pattern.c_str(), ...);
> )

Yes, you should be able to do this with gnulib.

> This is using the Debian package of gnulib, which is version
> 20111211+stable-1.

Good. This version contains usable support for the MSVC compiler.

> 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.

> 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=":"

> 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.

> 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.

Bruno