Patrick McMichael wrote:
> by default it builds a --enable-shared=yes library,
This isn't working right. Apparently something in the library changed
since the last time I tested it with Cygwin. I don't have time to chase
it right now, so for now, you're going to have to force it to use static
libraries, or go back to VC++.
If you're sticking with Cygwin, this patch will yield a static library:
--- configure.in (revision 1000)
+++ configure.in (working copy)
@@ -39,7 +39,8 @@
AM_INIT_AUTOMAKE
AM_CONFIG_HEADER(config.h)
AC_PROG_MAKE_SET
-AC_DISABLE_STATIC
+#AC_DISABLE_STATIC
+AC_DISABLE_SHARED
AC_PROG_LIBTOOL
AM_MAINTAINER_MODE
This is also the problem with MinGW, by the way: if you go with static
libraries, it works fine.
> I can't use a static library in a commercial application, can I?
Actually, that's not strictly true. You can discharge your obligations
under the LGPL if you're willing to distribute object files for your
program, so people can relink the program against a new MySQL++ library.
But if you're making a commercial application, why not use Visual C++?
Especially when your idea of an alternative seems to be Cygwin: it links
GPL code to your program unless you negotiate a support contract ($$$)
with Red Hat. The proper alternative here to VC++ is MinGW, not Cygwin.
> Hey, I liked the "twist it's arm" expression, sorry to see it go..
Objection noted. :)
> Which MinGW utilities are used? If it's only pexports
Also dlltool.
Yes, I realize Cygwin comes with dlltool...this is the result of trying
to minimize differences between those two FAQ items. Simpler to just
assume that you're using the MinGW version of both.
But this may be moot, as I think I'm going to distribute a def file with
MySQL++, so I'll only need to ask MinGW users to get dlltool, and
pexports won't be needed with either toolchain.
> The "libmysql.dll" has to be somewhere in the path, correct?
Of course. That, or in the current directory.
> Also, I've tried running pexports and dlltool on the MySQL++ .dll I
> generated with Visual Studio, but it causes dlltool to crash. Bummer.
This can't work anyway. g++ and VC++ use different C++ name mangling
schemes. Only C libraries are portable between the two. (If that
weren't the case, MinGW GCC couldn't link to the Win32 system DLLs.)
