Building MySQL++ 2.1.1 with MinGW

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




-- 
MySQL++ Mailing List
For list archives: http://lists.mysql.com/plusplus
To unsubscribe:    
http://lists.mysql.com/plusplus?unsub=gcdmc-plusplus@xxxxxxxxxxx