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:stream,
public OptionalExceptions, public Lockable"

becomes

"class MYSQLPP_EXPORT Query : public std:stream,
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:perator=.
To eliminate the warning, replace the declaration of
ResUse:perator= (result.h:92) with the definition of ResUse:perator=
(result.h:622) so that the function is defined within the class body of
ResUse.
Remove the inline keyword so that ResUse:perator= 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:perator=. 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-...ndex-_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....ttributes.html
(dllimport and dllexport attributes)
http://www.flounder.com/ultimateheaderfile.htm
http://www.parashift.com/c++-faq-lit...functions.html




--
MySQL++ Mailing List
For list archives: http://lists.mysql.com/plusplus
To unsubscribe: http://lists.mysql.com/plusplus?unsu...ie.nctu.edu.tw

Joel Fielder wrote:
Sigh....making the reverse change is exactly what _did_ work for me. It
was the way you're describing in earlier versions of MySQL++, and we got
more complaints about build failures on MinGW then. Are the MinGW
developers flip-flopping on this issue, or fixing long-standing
compatibility issues once and for all, or what?

I guess if they had to make it one way, I'd rather they do it the way
you're describing, since that's the VC++ way. But I gotta say, I'd like
some reassurance that this isn't going to just change again someday.

It also seems that you're using tools that aren't officially released
yet, so I wonder if I'm going to have to recommend that all MinGW users
do the same for it to work this new way?

Interesting. I don't understand why you have to do that to classes,
since the class proper isn't part of the DLL's interface; only its
member functions are.

Do you know if this works with VC++? If it breaks that, I won't be
applying it.

No doubt "repeat for all exported classes".

Without seeing the exact text of the warning, there's no way I'm making
that change. I'm not going to just blindly appease the compiler.

If it were me designing this library from scratch, I wouldn't have made
so many functions inline. Personal style. But I'm loathe to go and
move everything out of the headers and into the .cpp files on a "maybe"
sort of issue.

--
MySQL++ Mailing List
For list archives: http://lists.mysql.com/plusplus
To unsubscribe: http://lists.mysql.com/plusplus?unsu...ie.nctu.edu.tw

Linker warning:
warning: 'mysqlpp::ResUse& mysqlpp::ResUse:perator=(const
mysqlpp::ResUse&)' defined locally after being referenced with dllimport
linkage

My guess is that it's something to do with inheritance, and that placing
MYSQLPP_EXPORT in front of the class declaration ensures that members
from the base classes are properly exported also.

I'm sure it will work:
http://msdn2.microsoft.com/en-us/library/a90k134d.aspx, but confirmation
would be nice from someone running Visual C++


--
MySQL++ Mailing List
For list archives: http://lists.mysql.com/plusplus
To unsubscribe: http://lists.mysql.com/plusplus?unsu...ie.nctu.edu.tw

Joel Fielder wrote:
Oh, it's demented. Result:perator=() never is declared dllimport.
This must have to do with the changes to the way DLL linkage is handled
automatically now. It's incorrectly deciding it's an exported function
instead of an inline one.

I suppose if we have to hoist this inline up into the class definition,
we have to do it for all of them. I don't see anything that would make
this one operator special in that regard.

It's on the Wishlist now, for v2.2.

Ditto.

The MSDN library is confidence enough for me. It'll certainly get
tested before release, but I don't anticipate problems now. Thanks for
chasing this reference down.

--
MySQL++ Mailing List
For list archives: http://lists.mysql.com/plusplus
To unsubscribe: http://lists.mysql.com/plusplus?unsu...ie.nctu.edu.tw