bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Is gnulib supposed to support Visual Studio builds?


From: Daniel Schepler
Subject: Is gnulib supposed to support Visual Studio builds?
Date: Tue, 3 Jan 2012 14:47:11 -0800

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(), ...);
)
This is using the Debian package of gnulib, which is version
20111211+stable-1.

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+".)  Then, if I add --avoid to leave out those
modules which shouldn't be needed on Windows anyway, I run into problems
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.  (This is using Visual Studio 2008.)  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.  (I also needed to adjust glob.h not to try including
sys/cdefs.h, but aside from that the compilation worked OK.)

So my question is: is there any way to get the glob() function to be
available from a Visual Studio compiled program?  (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.)
-- 
Daniel





reply via email to

[Prev in Thread] Current Thread [Next in Thread]