SILLY link error when /MD option is set in demo program

[shenhui]

I've static linked to CEGUI 0.7.5 in my own project and found that when /MD(Multi-threaded DLL) option is set, there will be many link errors,:
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
1>msvcprt.lib(MSVCP80.dll) : error LNK2005: "public: __thiscall std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> >::~basic_string<char,struct std::char_traits<char>,class std::allocator<char> >(void)" (??1?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@QAE@XZ) already defined in SILLY.lib(SILLYImageLoaderManager.obj)
1>msvcprt.lib(MSVCP80.dll) : error LNK2005: "public: __thiscall std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> >::basic_string<char,struct std::char_traits<char>,class std::allocator<char> >(char const *)" (??0?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@QAE@PBD@Z) already defined in SILLY.lib(SILLYImageLoaderManager.obj)
1>msvcprt.lib(MSVCP80.dll) : error LNK2005: "public: __thiscall std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> >::basic_string<char,struct std::char_traits<char>,class std::allocator<char> >(class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > const &)" (??0?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@QAE@ABV01@@Z) already defined in SILLY.lib(SILLYImageLoaderManager.obj)
1>msvcprt.lib(MSVCP80.dll) : error LNK2005: "public: char const * __thiscall std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> >::c_str(void)const " (?c_str@?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@QBEPBDXZ) already defined in SILLY.lib(SILLYImageLoaderManager.obj)
1>msvcprt.lib(MSVCP80.dll) : error LNK2005: "public: unsigned int __thiscall std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> >::size(void)const " (?size@?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@QBEIXZ) already defined in SILLY.lib(SILLYImageLoaderManager.obj)
1>LINK : warning LNK4098: defaultlib 'LIBCMT' conflicts with use of other libs; use /NODEFAULTLIB:library
1>SILLY.lib(SILLYPNGImageLoader.obj) : error LNK2019: unresolved external symbol _png_error referenced in function "void __cdecl SILLY::PNG_read_function(struct png_struct_def *,unsigned char *,unsigned int)" (?PNG_read_function@SILLY@@YAXPAUpng_struct_def@@PAEI@Z)
1>SILLY.lib(SILLYPNGImageLoader.obj) : error LNK2019: unresolved external symbol _png_get_io_ptr referenced in function "void __cdecl SILLY::PNG_read_function(struct png_struct_def *,unsigned char *,unsigned int)" (?PNG_read_function@SILLY@@YAXPAUpng_struct_def@@PAEI@Z)
1>SILLY.lib(SILLYPNGImageLoader.obj) : error LNK2019: unresolved external symbol _png_get_channels referenced in function "public: virtual class SILLY::ImageContext * __thiscall SILLY::PNGImageLoader::loadHeader(enum SILLY::PixelFormat &,class SILLY::DataSource *)" (?loadHeader@PNGImageLoader@SILLY@@UAEPAVImageContext@2@AAW4PixelFormat@2@PAVDataSource@2@@Z)
1>SILLY.lib(SILLYPNGImageLoader.obj) : error LNK2019: unresolved external symbol _png_get_bit_depth referenced in function "public: virtual class SILLY::ImageContext * __thiscall SILLY::PNGImageLoader::loadHeader(enum SILLY::PixelFormat &,class SILLY::DataSource *)" (?loadHeader@PNGImageLoader@SILLY@@UAEPAVImageContext@2@AAW4PixelFormat@2@PAVDataSource@2@@Z)
1>SILLY.lib(SILLYPNGImageLoader.obj) : error LNK2019: unresolved external symbol _png_read_png referenced in function "public: virtual class SILLY::ImageContext * __thiscall SILLY::PNGImageLoader::loadHeader(enum SILLY::PixelFormat &,class SILLY::DataSource *)" (?loadHeader@PNGImageLoader@SILLY@@UAEPAVImageContext@2@AAW4PixelFormat@2@PAVDataSource@2@@Z)
1>SILLY.lib(SILLYPNGImageLoader.obj) : error LNK2019: unresolved external symbol _png_set_read_fn referenced in function "public: virtual class SILLY::ImageContext * __thiscall SILLY::PNGImageLoader::loadHeader(enum SILLY::PixelFormat &,class SILLY::DataSource *)" (?loadHeader@PNGImageLoader@SILLY@@UAEPAVImageContext@2@AAW4PixelFormat@2@PAVDataSource@2@@Z)
1>SILLY.lib(SILLYPNGImageLoader.obj) : error LNK2019: unresolved external symbol _png_set_error_fn referenced in function "public: virtual class SILLY::ImageContext * __thiscall SILLY::PNGImageLoader::loadHeader(enum SILLY::PixelFormat &,class SILLY::DataSource *)" (?loadHeader@PNGImageLoader@SILLY@@UAEPAVImageContext@2@AAW4PixelFormat@2@PAVDataSource@2@@Z)
1>SILLY.lib(SILLYPNGImageLoader.obj) : error LNK2019: unresolved external symbol _png_set_longjmp_fn referenced in function "public: virtual class SILLY::ImageContext * __thiscall SILLY::PNGImageLoader::loadHeader(enum SILLY::PixelFormat &,class SILLY::DataSource *)" (?loadHeader@PNGImageLoader@SILLY@@UAEPAVImageContext@2@AAW4PixelFormat@2@PAVDataSource@2@@Z)
1>SILLY.lib(SILLYPNGImageLoader.obj) : error LNK2019: unresolved external symbol _png_create_info_struct referenced in function "public: virtual class SILLY::ImageContext * __thiscall SILLY::PNGImageLoader::loadHeader(enum SILLY::PixelFormat &,class SILLY::DataSource *)" (?loadHeader@PNGImageLoader@SILLY@@UAEPAVImageContext@2@AAW4PixelFormat@2@PAVDataSource@2@@Z)
1>SILLY.lib(SILLYPNGImageLoader.obj) : error LNK2019: unresolved external symbol _png_create_read_struct referenced in function "public: virtual class SILLY::ImageContext * __thiscall SILLY::PNGImageLoader::loadHeader(enum SILLY::PixelFormat &,class SILLY::DataSource *)" (?loadHeader@PNGImageLoader@SILLY@@UAEPAVImageContext@2@AAW4PixelFormat@2@PAVDataSource@2@@Z)
1>SILLY.lib(SILLYPNGImageLoader.obj) : error LNK2019: unresolved external symbol _png_get_rows referenced in function "public: virtual bool __thiscall SILLY::PNGImageLoader::loadImageData(enum SILLY::PixelOrigin,class SILLY::DataSource *,class SILLY::ImageContext *)" (?loadImageData@PNGImageLoader@SILLY@@UAE_NW4PixelOrigin@2@PAVDataSource@2@PAVImageContext@2@@Z)
1>SILLY.lib(SILLYPNGImageContext.obj) : error LNK2019: unresolved external symbol _png_destroy_read_struct referenced in function "public: virtual __thiscall SILLY::PNGImageContext::~PNGImageContext(void)" (??1PNGImageContext@SILLY@@UAE@XZ)
1>SILLY.lib(SILLYPNGImageContext.obj) : error LNK2019: unresolved external symbol _png_get_image_height referenced in function "private: void __thiscall SILLY::PNGImageContext::setImageSize(void)" (?setImageSize@PNGImageContext@SILLY@@AAEXXZ)
1>SILLY.lib(SILLYPNGImageContext.obj) : error LNK2019: unresolved external symbol _png_get_image_width referenced in function "private: void __thiscall SILLY::PNGImageContext::setImageSize(void)" (?setImageSize@PNGImageContext@SILLY@@AAEXXZ)
1>../../../../bin/Sample_Demo6_Static.exe : fatal error LNK1120: 14 unresolved externals
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
We know that runtime library in CEGUI 0.7.5 used /MT option, so I guess it is the SILLY.lib built as /MT set that caused the above link error.
Could you guys provide us some solution about this? I think many projects will set their runtime library to /MD.

And I also found that CEGUI 0.6.0 used /MD option, but CEGUI 0.7.5 changed it, why?

Thanks very much.

SHEN Hui.

[CrazyEddie]

If you want to use the dynamic runtime option (/MD and /MDd options), you need to ensure that you also use dependency libraries compiled with that option. Since you're using the precompiled dependencies, this means using the libs in the 'dynamic' subdirectory, which can be achieved by setting the STATIC_BUILD_WITH_DYNAMIC_DEPS option to true in the config.lua file, rerunning the appropriate premake batch file and rebuilding the solution. This will address the 'already defined' errors.

The missing symbol errors are because when linking statically, you must also remember to link any dependencies of the CEGUI dependency libraries; for SILLY, this means things like libpng, jpeg, zlib and so on.

The use of /MT and /MTd by default for static builds is because that is the static runtime. If you're going to link statically you may as well go the whole hog, right? Unless you're just trying to hide your use CEGUI In any case, as mentioned above, there is an option to enable the use of either runtime.

CE

[shenhui]

Hello CE,

Thanks for your reply.

I did not want to hide my use CEGUI, I just do not want to attach so many dynamic denpendencies with my project, I think SILLY is built with /MT option, if we change the runtime library option as /MD for CEGUI Samples and CEGUI library, all of samples can not be linked correctly as well.

Since CEGUI declears to support static link, why not provide both static libraries with /MD and /MT options separately?

SHEN Hui.

[CrazyEddie]

There are two sets of libs. The ones in the dynamic subdir are using /MD and /MDd options, and yes these leave you with DLLs to distribute. The libs in the static subdir are built using the /MT and /MTd options, and are fully statically linked.

The user is, of course, free to compile the dependency libs themselves using whatever compile options and runtime choice they desire. I have provided a choice of two prebuilt sets of libs using common configurations as a courtesy to Win32 users - beyond this, it's as easy for the user to compile the dependencies as it is for me, especially since I'm not a Windows user - except when absolutely forced

CE.

[shenhui]

Hi CE,

Thanks for your help.

Where can I retrieve the source code of the dependencies and the version of source code your team use?
Could you please point out the link to source code of all dependencies ?

SHEN Hui

[CrazyEddie]

I develop on Linux, not Windows, and as such, for dependencies I use whatever version happens to be the latest installed on my system; there are no special version requirements for the dependencies, other than basically something reasonably recent - something released in the past couple of years (or the last release in the absence of a recent release).

As has been discussed previously - and I suspect you already know this - we do not, and will not, be providing source based dependencies for Windows (or any other platform). Though I will reiterate, that if someone wants to create and support such a thing, I am happy to go along with that, but it is absolutely not something that I personally will be doing.

The source for each dependency library that you desire to use can be obtained via the website for that dependency (you may have to obtain 'sub-dependency' libs too - especially for the image libs).

The following is not explicitly aimed at the OP, but rather is a general statement to anyone and everyone:
I don't want to hear anybody whining about how 'difficult' it is to collect up the source packages and build the dependencies; it is exactly what I have done previously when making the existing binary dependency packs - so if I can do it, so can other people. If anyone still wants to whine about this, I would ask them just one question: why is my time less important than yours?

CE.