-
Notifications
You must be signed in to change notification settings - Fork 246
Ganglia GMond Native Windows
This page is for collecting ideas about how to compile a native Windows version of gmond.
The current version of gmond on Windows is compiled as a Cygwin application. This means that it depends on (and is limited by) the Cygwin environment and DLL for performing some C library functions and providing an interface to system metrics.
A native binary reads the system metrics directly from the OS, using a mechanism known as WMI provided by the OS vendor.
The Cygwin binary is compiled by the GCC binary included with Cygwin. Various other GNU tools (autoconf and friends) are also included in Cygwin, and used to prepare the source tree for a Cygwin build in much the same way as they are when building in a real UNIX environment. For building a native binary on Windows, these options are available:
| Tools | Benefits | Disadvantages |
|---|---|---|
| CYGWIN versions of GNU tools GCC, autoconf, automake, etc (using GCC's -mno-cygwin for `cross compiling' a non-Cygwin binary) | Consistency with the UNIX build procedure | |
| Microsoft Visual C | Popular tool among Windows developers. Includes Windows headers and stuff relating to WMI. | Requires duplication of the makefiles Microsoft's equivalents to Makefiles are in a proprietary format and may not be suitable for an open source project |
| MinGW (also known as MinGW32) | Consistency with the UNIX build procedure No need to install full Cygwin Can be run on a Linux host as a cross-compiler to build Windows executables |
When GCC is invoked under Cygwin, it will typically make a binary that links with CYGWIN1.DLL, using the Cygwin runtime to do things like I/O and emulation of some parts of the C library that are not provided by the Windows API. br However, it is not mandatory to use GCC in this way. By passing the -mno-cygwin option to GCC, it can be forced to build a binary that does not link with CYGWIN1.DLL. This has various benefits:
- Cygwin licensing constraints are avoided. Only Ganglia license applies.
- Less likelihood of problems on systems having multiple copies of CYGWIN1.DLL installed on the hard disk.
- No exposure to security issues in CYGWIN1.DLL, reducing the risk of a costly re-deployment of the application in a large enterprise.
This list is not meant to be complete, and is currently considered a work in progress. Please feel free to add suggestions:
- Modify configure.in to include an option for the Windows native build
- Modify configure.in to add -mno-cygwin to CFLAGS when doing a Windows native build
- Inclusion of any necessary header files for Windows (or provide a script that simplifies the process of finding these files on the local hard disk)
- Investigate any C library functions that are not provided natively, and include an appropriately licensed alternative in gmond, re-implement the function, or modify gmond so that it doesn't use the function.
- Development of metric module implementations using WMI
- Creation of MSI file for the Windows installer
- POSIX threads - resolved in trunk
- libConfuse must be linked statically
- metric modules - can these be dynamically linked?
- metric modules for WMI must be C++, gmond in trunk supports C++ metric modules
- APR on Windows - static or dynamic?
The CYGWIN compiler variable may need to be complemented with some additional variables:
#define OS_WINDOWS ''set if compiling either Windows variant, Cygwin or native
#define CYGWIN'' set if compiling without -mno-cygwin
#define WIN_NATIVE // set if compiling on MinGW, Visual C or CYGWIN with -mno-cygwin