MySQL++

Impossible to build with Cygwin?
Login

Impossible to build with Cygwin?

(1) By anonymous on 2018-09-22 15:17:58 [source]

I may have built MySQL++ successfully with Cygwin.

After my first effort (following Hackers.txt and README-Cygwin.txt) failed, I started over so I could document exactly which packages were required.  I used setup-x86_64.exe to install the basic Cygwin - no additional packages whatsoever - and then ran:
./bootstrap nodoc noex nomaint pedantic bat

Of course I got the error
'perl' is not recognized as an internal or external command, operable program or batch file.
but two good things happened:
1) .bakefile-gen.state was generated
2) Makefile.mingw was generated

The problem I'd had - starting with the *full* set of packages - is that ./bootstrap abends with this error:
IOError: [Errno 13] Permission denied: '.bakefile_gen.state'.
I eventually discovered that, when .bakefile_gen.state is generated, it gets saved as a hidden file.  Removing the Hidden file attribute allowed ./bootstrap to at least finish.

Back to my bare-bones Cygwin build:
I removed the Hidden attribute from .bakefile_gen.state, added the Perl library (per Hackers.txt) and ran ./bootstrap again.  It finished, but generated 0 files.

I installed autoconf (per Hackers.txt) and tried again.  0 files.

I installed libmysqlclient-devel (per README-Cygwin.txt); still 0 files.

Reading the bootstrap script, I installed and tried make and automake, one-at-a-time.  0 files.

I abandoned ./bootstrap and tried (in Cygwin) mingw32-make -f Makefile.mingw, only to discover it expected to find MySQL Connector C 6.1 under C:\Program Files instead of C:\Program Files (x86).  I edited Makefile.mingw and it worked!

Then I remembered that README-MinGW.txt mentioned the Connector C path and there, I found the missing piece for ./bootstrap:
"If you're doing deeper work on MySQL++, you should change the MYSQL_WIN_DIR variable at the top of mysql++.bkl instead."

After that, ./bootstrap generated 55 files!  I don't know where or what they are because I think I'm close to getting the test files generated by mingw32-make to work.  (Pretty sure I have to populate my.cnf next.)

I hope these two details will help others avoid frustration when compiling MySQL++ for Windows.

(2) By Warren Young (tangent) on 2018-09-26 02:45:39 in reply to 1 [link] [source]

./bootstrap nodoc noex nomaint pedantic bat

I've rewritten that section of HACKERS.md to explain why that is not a useful command. You want some subset of it, either without "pedantic" or without "bat", depending on what you're trying to accomplish.

'perl' is not recognized as an internal or external command

Without Perl, you won't get lib/querydef.h or lib/ssqls.h when bootstrapping from a Fossil checkout. You can use MySQL++ without the latter, but I think the library won't compile without the former.

You can copy those over from a release tarball, though.

Removing the Hidden file attribute allowed ./bootstrap to at least finish.

I see two possibilities:

  1. It's a bug in Bakefile under Cygwin, in which case you should report that bug upstream.

  2. The problematic file mode is coming from an inherited NTFS ACL, which is a PITA to debug. This is most likely if you have relocated your Cygwin home directory from its default, c:\cygwin64\home\$USERNAME. In the default location, there are no weird ACLs floating around to bite you.

I assume you are using the latest Bakefile 0.x release, not 1.x?

added the Perl library

Maybe I'm just being pedantic, but Perl is a programming language, not a library. We only need a basic installation of Perl to bootstrap MySQL++, not any nonstandard Perl libraries. In Cygwin, this means we need only the perl package, not any of the hundreds of perl-* library distribution packages available for Cygwin.

mingw32-make -f Makefile.mingw

Do realize that MinGW and Cygwin builds are very different, even when you do a MinGW build underneath Cygwin. Pick one or the other; you can't mix them.

it expected to find MySQL Connector C 6.1 under C:\Program Files

Yes, that's one of the difficulties on Windows. You have the 32- vs 64-bit thing, you have Oracle moving the library about occasionally, and then on top of that you have poor local scripting abilities so we can't just go seek it out at build time.

Well, we could require this bootstrap process and Cygwin, which would get us strong scripting capabilities, but as you've seen, it's not terribly user-friendly!

Contrast a Unix-like system, where one of the many things Autoconf does for us is find out where the MySQL or MariaDB client libraries are installed, automatically.