Re: error LNK2005: public: int __thiscall std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> >::compare(char const )const (compare basic_string char_traits std allocator std already defined
mathieu wrote:
On Feb 16, 10:18 pm, mathieu <mathieu.malate...@gmail.com> wrote:
On Feb 16, 7:40 pm, "Alex Blekhman" <tkfx.REM...@yahoo.com> wrote:>
"mathieu" wrote:
I am getting those weird linker errors (using the Free Toolkit
2003), they do not appear using VS2005:
Wait: just for the record, you are _NOT_ mixing output of different C++
compilers, right? If you want to use C++ interfaces (e.g. from a DLL), they
must be compiled with the same compiler.
Just for reference my compiler flag are perfectly fine, and I was
using all the correct libraries. But there is one thing you cannot
do in MSC compiler:
#if defined(WIN32)
#if (defined(gdcmCommon_EXPORTS)
#define GDCM_EXPORT __declspec( dllexport )
#else
#define GDCM_EXPORT __declspec( dllimport )
#endif
#else
#define GDCM_EXPORT
#endif
class GDCM_EXPORT String : public std::string { ... }
I see one problem here: std::string is not intended as baseclass, so the
library in question already uses questionable constructs. If you want to
implement a type in terms of std::string you should wrap is as a member (or
at most a private baseclass), otherwise it can well be extended using plain
functions, just like the STL doesn't force every algorithm into the
containers but keeps them externally, too.
Anyway, neither of this is really your problem. The problem is rather that
this code will also implicitly export parts of std::string from that DLL. I
personally consider that a bug in the compiler. Now, what happens is that
in one translation unit you include <gcdm/string.h>, which tells the
compiler it can import std::string functions from the DLL, while in another
translation unit you only include <string> which generates those functions
inline. At link time, those definitions then cause
error LNK2005: "public: int std::string::compare(char const *) const"
already defined in TestFilename.obj
Now, the simple workaround is to include <gcdm/string.h> in both translation
units.
Could someone please let a poor UNIX guy understand what is the issue
here (I have very little knowledge on ho dll actually works) ?
Basically DLLs are like Unix shared objects, only that you have to
explicitly say which parts are exported via __declspec(dllexport). Your
issues have nothing to do with the differences between SOs and DLLs though,
they are rather a compiler bug.
Uli
--
C++ FAQ: http://parashift.com/c++-faq-lite
Sator Laser GmbH
Gesch??ftsf??hrer: Michael W??hrmann, Amtsgericht Hamburg HR B62 932