List:MySQL++« Previous MessageNext Message »
From:Joel Fielder Date:June 29 2006 8:48am
Subject:Building MySQL++ 2.1.1 with MinGW
View as plain text  
Hello,

I have encountered similar build problems to those highlighted on the
list recently: "vtable for mysqlpp::xxx can't be auto-imported....".
Specifically, I am using:

MySQL++ 2.1.1
MinGW g++ 3.4.5
MinGW core 3.4.5
MinGW binutils 2.16.91

I was able to successfully build the mysqlpp library by following
exactly the instructions given in readme.mingw, but when building the
examples, I received the auto-import error.

In order to solve the build problem, changes to \examples\Makefile.mingw
and to the library source code were required:

Step 1:

	Remove all "-DMYSQLPP_NO_DLL" switches from
\examples\Makefile.mingw.
	This ensures that the preprocessor puts __declspec(dllimport) in
place of MYSQLPP_EXPORT which allows the use of mysqlpp.dll.

Step 2:

	At query.h:115, insert MYSQLPP_EXPORT into the class declaration
of Query:

 	"class Query : public std::ostream,
	public OptionalExceptions, public Lockable"

	becomes

	"class MYSQLPP_EXPORT Query : public std::ostream,
	public OptionalExceptions, public Lockable"

Step 3:

	Repeat step 2 for the class declarations of Row (row.h:48),
ResUse (result.h:61), and Fields (fields.h:41)
	Repeat once more for the struct declaration of Date
(datetime.h:210).

Step 4:

	The examples will build without error after making the previous
changes, but there will be a warning regarding ResUse::operator=.
	To eliminate the warning, replace the declaration of
ResUse::operator= (result.h:92) with the definition of ResUse::operator=
(result.h:622) so that 	the function is defined within the class body of
ResUse.
	Remove the inline keyword so that ResUse::operator= becomes:

	ResUse& operator =(const ResUse& other)
	{
		if (this == &other) {
			return *this;
		}
		copy(other);
		other.result_ = 0;
		return *this;
	}

This should not affect non-Win32 platforms because in those cases, the
MYSQL_EXPORT macro is defined to nothing (see platform.h).  A test in
VisualC++ is warranted.

I do not believe that there are significant implications of moving
ResUse::operator=. My understanding is that member functions defined
within the class body are treated as inline.  As an aside, inline
functions within a DLL header can lead to version conflicts...  Is that
a worry?  Probably not (since anyone can re-compile the DLL), but
perhaps worth bringing up.

Thanks,

Joel

References:

http://sourceware.org/binutils/docs-2.16/ld/Options.html#index-_002d_002
denable_002dauto_002dimport-270
http://msdn2.microsoft.com/en-us/library/z4zxe9k8.aspx
http://msdn2.microsoft.com/en-us/library/feffc7b5.aspx (importing and
exporting inline functions)
http://gcc.gnu.org/onlinedocs/gcc-3.4.4/gcc/Function-Attributes.html
(dllimport and dllexport attributes)
http://www.flounder.com/ultimateheaderfile.htm
http://www.parashift.com/c++-faq-lite/inline-functions.html



Thread
Building MySQL++ 2.1.1 with MinGWJoel Fielder29 Jun
  • Re: Building MySQL++ 2.1.1 with MinGWWarren Young30 Jun
    • Re: Building MySQL++ 2.1.1 with MinGWCarlos Flores30 Jun
    • Re: Building MySQL++ 2.1.1 with MinGWJoel Fielder3 Jul
      • Re: Building MySQL++ 2.1.1 with MinGWWarren Young5 Jul