Yes, it builds just fine, both from within the Xcode environment and at the command line. We currently test only on the current and/or prior releases of the OS. The included Xcode project files should work with Xcode 2+, which implies that it may still build on systems as old as OS X 10.4. In the past, we successfully tested command line builds on a 10.3 box.

Command line builds are still preferred to Xcode, as there is more flexibility to be had here. See `README-Mac-OS-X.txt` in the MySQL++ tarball for details. That file also contains instructions on getting [Connector/C](https://dev.mysql.com/downloads/connector/c/) for macOS, which MySQL++ builds against.


## <a name="cygwin"></a>Will it build under Cygwin?

Yes. See [the `README-Cygwin.txt` file](/file/README-Cygwin.txt).
Yes. See [the `README-Cygwin.txt` file](/doc/trunk/README-Cygwin.txt).


## <a name="mingw"></a>Will it build under MinGW?

Yes. Occasionally a version of MinGW comes out that breaks MySQL++, but there has always been a usable workaround.

Once you have your problem boiled down to a simple example, send the source code to the mailing list along with a detailed report. We want to know what you expect the program to do, and what it actually does on your machine. Keep in mind, programs often behave differently on different systems. As a programmer yourself, you know what it is like to
deal with vague user bug reports. Give us the sort of error report you’d like to receive for your programs.


## <a name="patches"></a>How do I submit a change to MySQL++?

This is covered in detail in [the `HACKERS.txt` file](/file/HACKERS.txt).
This is covered in detail in [the `HACKERS.txt` file](/doc/trunk/HACKERS.txt).

But in brief: we want the patch in unified diff format, made against either the latest release of MySQL++ or (preferably) against [the trunk of the Fossil repository](/timeline?r=trunk). You can send it either to the [mailing list](http://lists.mysql.com/plusplus/), or to [the ticket tracker](/ticket). We prefer that you only use the ticket tracker for patches that are so trivial or obvious that they won’t need discussion.

When a patch is rejected, the most common reason is that it breaks the library’s binary interface (ABI), so that an old program can’t link to the changed library without recompiling. We only make such changes at major version transitions. These transitions are rare, and we can’t even promise that there will ever be another one, much less when it will occur. If you have a choice of two ways to get your desired effect and one of them doesn’t break the ABI, it will increase the chances that we accept your patch if you do it that way.