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
