[Fixed] Visual C++ - Linking error with /MT option.

[gontai]

Hi, there. I'm using SFML 2.0 (rev. 1516) and Visual Studio 2008.

Before I use this, rev 1516, there is no error to compile.

Code: [Select]

1>MSVCRT.lib(MSVCR90.dll) : error LNK2005: _abort already defined in LIBCMTD.lib(abort.obj)
1>MSVCRT.lib(MSVCR90.dll) : error LNK2005: ___iob_func already defined in LIBCMTD.lib(_file.obj)
1>MSVCRT.lib(MSVCR90.dll) : error LNK2005: _fwrite already defined in LIBCMTD.lib(fwrite.obj)
1>MSVCRT.lib(MSVCR90.dll) : error LNK2005: _ferror already defined in LIBCMTD.lib(feoferr.obj)
1>MSVCRT.lib(MSVCR90.dll) : error LNK2005: _fflush already defined in LIBCMTD.lib(fflush.obj)
1>MSVCRT.lib(MSVCR90.dll) : error LNK2005: _exit already defined in LIBCMTD.lib(crt0dat.obj)
1>MSVCRT.lib(MSVCR90.dll) : error LNK2005: _sprintf already defined in LIBCMTD.lib(sprintf.obj)
1>MSVCRT.lib(MSVCR90.dll) : error LNK2005: _longjmp already defined in LIBCMTD.lib(longjmp.obj)
1>MSVCRT.lib(MSVCR90.dll) : error LNK2005: _getenv already defined in LIBCMTD.lib(getenv.obj)
1>MSVCRT.lib(MSVCR90.dll) : error LNK2005: _malloc already defined in LIBCMTD.lib(dbgmalloc.obj)
1>MSVCRT.lib(MSVCR90.dll) : error LNK2005: _free already defined in LIBCMTD.lib(dbgfree.obj)
1>MSVCRT.lib(ti_inst.obj) : error LNK2005: "private: __thiscall type_info::type_info(class type_info const &)" (??0type_info@@AAE@ABV0@@Z) already defined in LIBCMTD.lib(typinfo.obj)
1>MSVCRT.lib(ti_inst.obj) : error LNK2005: "private: class type_info & __thiscall type_info::operator=(class type_info const &)" (??4type_info@@AAEAAV0@ABV0@@Z) already defined in LIBCMTD.lib(typinfo.obj)


Yes, this is the problem "/MT" and "/MD" option to link.

But in the past, compiled with no error.

And I was found what extra library has changed to static library.

I think png.lib or jpeg.lib compiled with "/MD" option.

If this is correct, I don't want to use "/MD" option because it needs MFC DLL.

Is there another solution in this case?




FIX: not MFC DLL, it needs MSVCR90.dll.

[Ashenwraith]

use code::blocks :wink:

[Laurent]

Everything is compiled using "Multithreaded [debug] DLL" (I guess it's /MT and /MTd). You shouldn't have any problem, the samples compile fine for example. Try "rebuild all"

And why are you talking about MFC? You don't need any MFC DLL if you're not using MFC.

[gontai]

Oops.. My mistake what I guess that is mfc dll. I'm sorry this wrong information..   :cry:

When I compile /MD or /MDd("Multithreaded [debug] DLL"), it has problem MSVCR90.dll dependency that needs Microsoft Visual C++ Redistributable Package.

Maybe they(jpeg.lib, png.lib, soil.lib, and glew.lib) compiled /MD(d), but I want /MT(d)... OTL


The switch means ..

/MT  : Multi-Threaded
/MTd : Multi-Threaded Debug
/MD  : Multi-Threaded DLL
/MDd : Multi-Threaded Debug DLL

[Laurent]

You can't use /MT if SFML is compiled with /MD. Just distribute the VC++ binaries, like every other project does. Almost everyone has theses files anyway.

Or you can recompile SFML with the /MT option.

[gontai]

I'm sorry that did not properly explain the situation is, because of my bad English. T-T

The error is when my program to use /MT, and SFML complied with /MT option.

But extLibs(jpeg.lib, png.lib, soil.lib, and glew.lib) are compiled with /MD(I guess)..

So SFML compile with /MT option is OK, because they just add extLibs.

But my program to use SFML, I met this errors.


Well, I just try to this extLibs to use /MT option, get the sources from internet, and compiled. And then replace in the SFML's extLibs, my program is compiled with no error(with some warnings).

How about this? ExtLibs compile with /MT option. Then the program compiled fine with any options(/MT(d) or /MD(d)). In the past everything is fine because extLibs(jpeg.lib, png.lib, soil.lib, glew.lib) were not static library.



Thank you for read this article.

[Laurent]

External libs are compiled with the same options as the SFML libraries. And like I already said, the SFML samples compile and link with no error -- did you try to compile them?

[gontai]

When SFML compile is no problem with any options(/MT or not), but using SFML that compiled with /MT option has a problem.


Try this, in order please.

1. SFML libraries changes to /MT(d) option and compile, because the program(in this, I will use sample win32 for example) want to /MT(d) option.

   - no error.

2. win32 sample changes to /MT(d) option and compile .

   - link error.

3. jpeg.lib, png.lib, soil.lib and glew.lib compile with /MT option.

4. SFML libraries compile with /MT or /MD option.

   - no error.

5. win32 sample compile with same SFML option.

   - no error.



The point is I want to compile with /MT but I can't.

[Laurent]

Ok I see!

So you want to (re)compile everything with /MT.

If it works when you recompile the external libs with /MT, then use this modified version. What do you want me to do exactly?

[gontai]

That's right.

Maybe SFML library and samples with /MD option work correctly, even if the External libraries(jpeg.lib, png.lib, soil.lib and glew.lib) compile with /MT option.


I think, there is two way.

1. The external libs are integrated to the source code like before, or the source code and their project files.

2. The external libs compile with /MT option.



Thank you for reading this, again.

[Laurent]

May I ask why you want to compile with /MT?

[gontai]

I want to work like this.

http://groups.google.co.kr/group/microsoft.public.vc.language/msg/0f59d7a560a0cbdc?pli=1


/MD option needs MSVCRxx.dll.

If there is no MSVCRxx.dll, the target machine has to install Microsoft Visual C++ Redistributable Package.

[Laurent]

Ok I see. Anyway, I can't help you, I'm sorry. You will have to create projects for the external libraries and compile them yourself with the proper options.

[gontai]

Ok. Thank you. I'll try.