List:MySQL++« Previous MessageNext Message »
From:Nils Woetzel Date:June 9 2007 6:55pm
Subject:LNK2005 visual studio 2005
View as plain text  
Hi everybody,

we are using mysql++ for quite a long time and started with version 2.1.1.


I've tried to update our project to use 2.2.0 some time ago and got a linker
error. I was waiting to release 2.2.3, but I still get the same error.


My setup:

Visual studio 2005

Mysql 5.0.41

Mysql++ 2.2.3


Mysql++ is compiling just fine.


But when my project is linking with mysqlpp.lib(mysqlpp.dll), I get 34
errors related to a std::vector<std::string>

mysqlpp.lib(mysqlpp.dll) : error LNK2005: "public: __thiscall
std::vector<class std::basic_string<char,struct std::char_traits<char>,class
std::allocator<char> >,class std::allocator<class
std::basic_string<char,struct std::char_traits<char>,class
std::allocator<char> > > >::~vector<class
std::char_traits<char>,class std::allocator<char> >,class
std::allocator<class std::basic_string<char,struct
std::char_traits<char>,class std::allocator<char> > > >(void)"
@@std@@QAE@XZ) already defined in bcl_align.obj



I just show one of the errors, since the others are basically the same, just
for other functions of the std::vector.


After reading through the mailing list several times and reading this
article three times:


which essentially says, that when you explicitly export a std::vector this
can cause multiply-defined symbol errors,

I was looking in the history of the header files that have changed in the
past versions, I figured out that it might have something to do with the
usage of the MYSQLPP_EXPORT tag which was not used in front of classes in
previous verisons, but are now always and everywhere used. And this since
version 2.2.0 - The svn comments are saying this was done to resolve issues
with MinGW.

By the way, compiling the dll with MinGW of version 2.2.3 works just fine
and links with my project using mingw.


Anyways, I tried to resolve the problem, and found two solutions:

One is using the compiler flag in visual studio:


Which disables incremental building and slows down linking significantly,
and brings the errors as warnings. I did not like that.

So I tried to get rid of MYSQLPP_EXPORT related to all
std::vector<std::string> instantiations, which are only found for the
FieldNames class. (field_names.h and row.h)


Index: C:/Documents and Settings/Nils/workspace/mysql++/lib/field_names.h


--- C:/Documents and Settings/Nils/workspace/mysql++/lib/field_names.h
(revision 1554)

+++ C:/Documents and Settings/Nils/workspace/mysql++/lib/field_names.h
(working copy)

@@ -42,7 +42,7 @@



 /// \brief Holds a list of SQL field names

-class MYSQLPP_EXPORT FieldNames : public std::vector<std::string>

+class FieldNames : public std::vector<std::string>



            /// \brief Default constructor

@@ -97,7 +97,7 @@




-           void init(const ResUse* res);

+          MYSQLPP_EXPORT void init(const ResUse* res);



 } // end namespace mysqlpp



Index: C:/Documents and Settings/Nils/workspace/mysql++/lib/row.h


--- C:/Documents and Settings/Nils/workspace/mysql++/lib/row.h
(revision 1554)

+++ C:/Documents and Settings/Nils/workspace/mysql++/lib/row.h
(working copy)

@@ -43,7 +43,7 @@


 #if !defined(DOXYGEN_IGNORE)

 // Make Doxygen ignore this

-class MYSQLPP_EXPORT FieldNames;

+class FieldNames;




This resolved the entire linking issue in visual studio.

But now the problem might be that mingw will not do what it was supposed to
do (at least what the comments in svn are saying).

But building with mingw still works for me (I use g++ of mingw, but the
cygwin make), I am not sure about other building systems, but since this is
was only important for the windows dll I guess there might not be a reason
to export the entire Field_Names class, but only the "Init" function.


Please let me know if I did something wrong, or what I should have done to
handle this linker error.

I am sure that I used the correct project settings from the examples which I
checked multiple times.


Thanks a lot





LNK2005 visual studio 2005Nils Woetzel9 Jun
  • Re: LNK2005 visual studio 2005casper china18 Jun
  • Re: LNK2005 visual studio 2005Warren Young19 Jun
    • RE: LNK2005 visual studio 2005Joel Fielder19 Jun