FAQ
Hi all,

is it possible to compile the MySQL++ library so I can use it in an
application that needs to be built as "MFC in a static library" and
"Multithreaded (/MT)"?

My build environment: MS VC 7.1.6030 (VS2003), WinXP, MySQL 5.0.58 commercial.

My problem:
If I compile MySQL++ as "Multithreaded DLL (/MD)" it does not link
with my application (getting lots of unresolved externals linker
errors of STL stuff like
---8<--------------
error LNK2019: unresolved external symbol '"__declspec(dllimport)
public: void __thiscall std::basic_ostream<char,struct
std::char_traits<char> >::_Osfx(void)"
(__imp_?_Osfx@?$basic_ostream@DU?$char_traits@D@std@@@std@@QAEXXZ)',
used in function '"public: __thiscall std::basic_ostream<char,struct
std::char_traits<char> >::sentry::~sentry(void)"
(??1sentry@?$basic_ostream@DU?$char_traits@D@std@@@std@@QAE@XZ)'
--->8--------------
).

If I compile MySQL++ as "Multithreaded (/MT)" it links but my
application crashes when Calling the str() methods of Query and
DateTime instances when leaving the current scope.
You can easily verify this by compiling just the mysqlpp-Project as
"/MT" and add
---8<--------------
mysqlpp::DateTime dt( 2008, 04, 22, 12, 22, 22 );
string qstr = dt.str();
cout << "test: " << dt << std::endl;
--->8--------------
to simple2.cpp.

Strangely, if I compile excommon and simple2 as "Multithreaded (/MT)"
it also does not link, although all should fit together in that case.

I would be very glad if anybody could shed some light on this issue(s)...

Thanks in advance,

-oli-
(O. Baum)

Search Discussions

  • O. Baum at Apr 22, 2008 at 3:51 pm
    Hi,

    thank You very much for Your quick reply!

    Please find some comments on Your answers inline.

    2008/4/22, Warren Young <mysqlpp@etr-usa.com>:
    There may, however, be a legal limitation here due to MySQL++'s LGPL
    license: if you distribute binaries statically linked to MySQL++, you also
    have to offer enough of the source code that people can relink your program
    to a new version of MySQL++. The LGPL lets you avoid this if you use
    dynamic linkage, which is why it's the default build option in the
    distribution for all platforms.
    You mean, that building MySQL++ with /MT generates a static library?
    This is not the case, as the mysqlpp[_d].dll in that case still is
    generated (and needed by the executable). I think the determination
    whether to build a dll or lib takes place in the "common" tab of the
    project properties where you need to select "static lib" as
    "configuration type"...
    I do not want to link statically due to LGPL.
    However, beware that the underlying MySQL C API library uses the even
    stricter GPL by default, unless you arrange for a commercial license for
    MySQL on the systems you run your program on.
    Thank You for this hin, but I know this, and we already own a
    commercial MySQL license (which I also wrote in my first mail).
    Strangely, if I compile excommon and simple2 as "Multithreaded (/MT)"
    it also does not link, although all should fit together in that case.
    I'm not entirely sure what it is you are doing, but the rule is simple: all
    modules in a single program have to be compiled with the same settings. You
    can't mix /MD or /MT flags among modules that get linked together into a
    single EXE. This is the way VC++ works.
    That's what I also thought before I tried the following:
    * open the mysql++.sln workspace from the vc2003 directory in my VC7.1;
    * compile (debug build) without changing settings;
    * works w/o linker errors; can execute binaries like simple1.exe etc.;
    * change Code Generation for "mysqlpp" project from "Multithreaded
    Debug DLL (/MDd)" to "Multithreaded Debug (/MTd)", rebuild all; (note
    that simple1 project is still configured as /MDd so I mixed the
    flags!)
    * works w/o linker errors, can execute binaries like simple1.exe w/o problems;
    * change Code Generation for "excommon" to /MTd;
    * rebuilding "excommon" results in 3 linker warnings, although mysqlpp
    and excommon have now the same /MTd flag: they look like
    ---8<-------
    cmdline.obj : warning LNK4006: '"public: class
    std::basic_ostream<char,struct std::char_traits<char> > & __thiscall
    std::basic_ostream<char,struct std::char_traits<char>
    ::operator<<(int)"
    (??6?$basic_ostream@DU?$char_traits@D@std@@@std@@QAEAAV01@H@Z)'
    bereits in 'mysqlpp_d.lib(mysqlpp_d.dll)' definiert; zweite Definition
    wird ignoriert
    --->8-------
    (have a German VS, message in English means "already defined in
    mysqlpp_d.dll, ignoring 2nd definition")
    * change Code Generation for "simple1" to /MTd;
    * rebuilding "simple1" results in 5 linker errors:
    ---8<-------
    mysqlpp_excommon.lib(mysqlpp_d.dll) : error LNK2005: "public: class
    std::basic_ostream<char,struct std::char_traits<char> > & __thiscall
    std::basic_ostream<char,struct std::char_traits<char> >::flush(void)"
    (?flush@?$basic_ostream@DU?$char_traits@D@std@@@std@@QAEAAV12@XZ)
    bereits in mysqlpp_excommon.lib(cmdline.obj) definiert
    mysqlpp_excommon.lib(mysqlpp_d.dll) : error LNK2005: "public: class
    std::basic_ostream<char,struct std::char_traits<char> > & __thiscall
    std::basic_ostream<char,struct std::char_traits<char> >::put(char)"
    (?put@?$basic_ostream@DU?$char_traits@D@std@@@std@@QAEAAV12@D@Z)
    bereits in mysqlpp_excommon.lib(cmdline.obj) definiert
    libcpmtd.lib(cerr.obj) : error LNK2005: "public: void __thiscall
    std::basic_ios<char,struct std::char_traits<char>
    ::setstate(int,bool)"
    (?setstate@?$basic_ios@DU?$char_traits@D@std@@@std@@QAEXH_N@Z) bereits
    in mysqlpp_excommon.lib(mysqlpp_d.dll) definiert
    libcpmtd.lib(cout.obj) : error LNK2005: "public: void __thiscall
    std::basic_ios<char,struct std::char_traits<char>
    ::setstate(int,bool)"
    (?setstate@?$basic_ios@DU?$char_traits@D@std@@@std@@QAEXH_N@Z) bereits
    in mysqlpp_excommon.lib(mysqlpp_d.dll) definiert
    E:\develop\LEOS_SRV\_new\mysql++-3.0.2\vc2003\Debug\simple1.exe :
    fatal error LNK1169: Ein oder mehrere mehrfach definierte Symbole
    gefunden
    --->8-------
    (last one meaning "one or more multiple defined symbols found")

    I have configured all projects with the same code generation option
    (/MTd) and it does *not* work. Any ideas on that?

    Thanks for your help in advance.

    Best regards,

    -oli-
    (O. Baum)
  • O. Baum at Apr 29, 2008 at 9:55 am
    Hi again,

    in the last days I did some extensive investigations on my problem.

    Let me first mention some facts about /MT and /MD and DLL creation:
    * It is normally no problem to create a DLL compiled with /MT.
    * The EXE which uses this DLL *should* be then also compiled with /MT
    to prevent strange effects from happening. These effects are described
    here <http://msdn2.microsoft.com/en-us/library/ms235460.aspx>.
    * A DLL interface can be designed in a way these effects do not occur.

    HOWEVER, one will run into a huge linkage problem IF one compiles a
    DLL with /MT AND the DLL interface contains classes which are derived
    from C(++)-std-lib's classes (like std::string, std::ostream etc.).
    Exactly this is the case in MySQL++: The Query class is derived from
    std::ostream, which leads to linkage errors LNK2005 and LNK1169 when
    trying to link the MySQL++ DLL with the main program's EXE.
    (All links and works correctly if all is compiled with /MD.)

    Could anybody help me please?
    I am not able to compile my main program's EXE with /MD, because I
    need to link MFC statically.
    I cannot compile MySQL++ with /MT because then the described "strange
    effects" (including corrupt stack, crash when calling CDateTime::str()
    etc.) occur.

    When I link MySQL++ statically all works, but this is not allowed due
    to LGPL restrictions.

    Thank you for help in advance!

    With best regards,

    O. Baum


    2008/4/22 O. Baum <oli.b@freenet.de>:
    Hi all,

    is it possible to compile the MySQL++ library so I can use it in an
    application that needs to be built as "MFC in a static library" and
    "Multithreaded (/MT)"?

    My build environment: MS VC 7.1.6030 (VS2003), WinXP, MySQL 5.0.58 commercial.

    My problem:
    If I compile MySQL++ as "Multithreaded DLL (/MD)" it does not link
    with my application (getting lots of unresolved externals linker
    errors of STL stuff like
    ---8<--------------
    error LNK2019: unresolved external symbol '"__declspec(dllimport)
    public: void __thiscall std::basic_ostream<char,struct
    std::char_traits<char> >::_Osfx(void)"
    (__imp_?_Osfx@?$basic_ostream@DU?$char_traits@D@std@@@std@@QAEXXZ)',
    used in function '"public: __thiscall std::basic_ostream<char,struct
    std::char_traits<char> >::sentry::~sentry(void)"
    (??1sentry@?$basic_ostream@DU?$char_traits@D@std@@@std@@QAE@XZ)'
    --->8--------------
    ).

    If I compile MySQL++ as "Multithreaded (/MT)" it links but my
    application crashes when Calling the str() methods of Query and
    DateTime instances when leaving the current scope.
    You can easily verify this by compiling just the mysqlpp-Project as
    "/MT" and add
    ---8<--------------
    mysqlpp::DateTime dt( 2008, 04, 22, 12, 22, 22 );
    string qstr = dt.str();
    cout << "test: " << dt << std::endl;
    --->8--------------
    to simple2.cpp.

    Strangely, if I compile excommon and simple2 as "Multithreaded (/MT)"
    it also does not link, although all should fit together in that case.

    I would be very glad if anybody could shed some light on this issue(s)...

    Thanks in advance,

    -oli-
    (O. Baum)
  • Warren Young at Apr 29, 2008 at 11:04 am

    O. Baum wrote:

    HOWEVER, one will run into a huge linkage problem IF one compiles a
    DLL with /MT AND the DLL interface contains classes which are derived
    from C(++)-std-lib's classes (like std::string, std::ostream etc.).
    Exactly this is the case in MySQL++: The Query class is derived from
    std::ostream, which leads to linkage errors LNK2005 and LNK1169 when
    trying to link the MySQL++ DLL with the main program's EXE.
    (All links and works correctly if all is compiled with /MD.)

    Could anybody help me please?
    I don't know of any easy answers. You could:

    1. Change the parentage of Query and a whole lot of other classes (Row,
    Fields, etc.) If you provided the patches, at best they would be
    accepted no earlier than v4, which could be years away. More likely,
    this would cause a development fork.

    2. Switch to MinGW, which shouldn't have these limitations, but you'd
    have to change GUI frameworks, too. If you don't have much code written
    yet, this may be practical, but probably not otherwise.

    3. Find some other C++ wrapper for MySQL.

    4. Forget C++ wrappers, and use the underlying MySQL C API instead.
  • Joseph Artsimovich at Apr 29, 2008 at 1:59 pm

    Could anybody help me please?
    I am not able to compile my main program's EXE with /MD, because I
    need to link MFC statically.
    I am not sure why you insist on having MFC statically linked, while you
    don't mind linking MySQL++ dynamically.
    I haven't programmed with MFC, but theoretically it should be possible
    to link MFC statically to a program compiled with /MD. In that case,
    MFC needs to be compiled with /MD as well, but not as a DLL, but as a
    static library.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupplusplus @
categoriesmysql
postedApr 22, '08 at 12:34p
activeApr 29, '08 at 1:59p
posts5
users3
websitemysql.com
irc#mysql

People

Translate

site design / logo © 2022 Grokbase