On Thu, Sep 25, 2008 at 10:14:14PM +0100, [EMAIL PROTECTED] wrote: > > I am aware of mingw32 - however, a Cygwin environment provides autoconf > and friends.
there is also a similar environment for mingw called msys but there is no reason (neither I'd recommend) using it when you can just as well install gcc-mingw in cygwin and have both. > Do you propose: > a) running configure on Linux and then mingw on Windows, or > b) running mingw32 within a Linux host to cross-compile for Windows, or > c) is there a complete way to build directly from a fresh SVN checkout > on Windows using the mingw32 tools and native autotools executables? not sure what you meant here, but as you explained before ./configure works in cygwin using mingw : # CC="gcc -mno-cygwin" ./configure and you can also cross-compile for linux using mingw if inclined, and last I checked you could also bootstrap trunk in cygwin if you wanted to and configure/build libmetrics either as a cygwin library or as a native windows library. > Regarding the C++ issues and Posix thread issues: is there any intention > to back port this to 3.1.x, or is there another release that these are > targetted for? I'm not too worried either way, I just want to be able > to focus my efforts in the right versions. the C++ issues and some of the fixes needed to build libmetrics as a native windows library has been proposed for backport into 3.1 for sometime already but have no votes yet, I don't see any reason to keep them only on trunk but in any case all development happens in trunk, so that is where you have to focus anyway and I would imagine this might be material for 3.2 once all pieces are put in place but since fixing DSO support for windows is in the TODO list for 3.1 some of that code will have to be backported anyway. there were no fixes implemented for the "Posix thread vs Native thread" yet but this issue has been talked about several times before and I remember you mentioning at least once you had done work with some library that could be used to abstract the differences in one of the last threads, but haven't yet read any specifics I could share and I am too lazy to search in the mailing list for links. > Regarding libConfuse: can you refer me to any previous postings on the > issue of libConfuse static build on Windows? Is this a limitation that > originates upstream? libConfuse limitations comes from upstream, which is why the only viable solution for now will be to link it statically (as it is done in cygwin) and unless the upstream version is fixed and we then rely on that yet not existant version. > I'm not a big fan of the srclib concept myself, but I don't see why > there shouldn't be snapshots of essential dependencies in another part > of the SVN repository, not directly under the Ganglia sub-tree. because then you will need to pull all the pieces by hand to build it and then you wouldn't have ever a standalone package (snapshot or release) that could be used. in any case having the build use a "srclib" provided libconfuse statically if none is available or when instructed by doing --with-libconfuse=internal or something like that is far better than any alternative AFAIK. > Also, I remember seeing something about problems running dynamically > linked metric modules on Windows - is that the case? If so, is it > something that can be overcome if someone is willing to work on it? The > APR docs seem to suggest that it is intended to support Windows DLLs. If building a native windows version, linked to a windows APR maybe, but not if building inside cygwin as APR will try then to use the UNIX code and fail. this is IMHO an APR deficiency which shows also when trying to for example build apache using DSO inside cygwin. there is also the problem that in windows (like in AIX) all objects must be resolved at link time and sadly our build process is not clean enough to ensure that yet (even if it works in Linux and other platforms like Solaris/BSD where the dynamic linker does lazy binding to cover for our build process deficiencies) Carlo ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Ganglia-developers mailing list Ganglia-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-developers
