Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Adding libraries

Status
Not open for further replies.

scecilia

Programmer
Jul 8, 2002
35
US
Hi,

I inherited a piece of code which was initially written on a Unix platform and I am trying to convert to Windows. This code uses the library FFTW2st.lib. I added the library to the application settings but then I get a some link errors saying that I have duplicate definitions such as malloc(),etc, does anyone knows what the problem might be?

--Cecilia.
 
malloc() etc. are defined in another win32 - libraries, and linker does not know, where are the right functions. You can try to remove some win32 libraries from project, but i don't think it will work with unix memory alloication under windows. You should try to find win32 libraries with functions You needs (if such exists) or rewrite Your programm - there are no another ways.
 
Hi Ttouch,

Thanks for your reply. I am actually the one working on this problem. Cecilia was kind enough to post the question for me, as I was not registered yesterday.

The library she mentioned, FFTW2st.lib, is a Win32-based library for Fast Fourier Transforms. Its header file, fftw.h, does #include <stdlib.h>, which declares malloc(). An e-mail message from the author of the library indicates that this problem is evidently a conflict between the malloc defined in <stdlib.h> and similar versions of malloc() etc. that are defined independently when in debug is turned on, as it presently is. The actual error message created by the linker is below.

MSVCRT.lib(MSVCRT.dll) : error LNK2005: _malloc already defined in LIBCD.lib(dbgheap.obj)

II delete the #include <stdlib.h>, then the conflict goes away, but then unfortunately the linker cannot then find malloc() or free(). So, the problem is now how to declare/define malloc() and free() when debug mode is turned on.

I'm sorry, I do not understand your comment about unix functions and rewriting code. Malloc() and free() are supported by Visual C++. The question is, how?

Thanks,

Peter
 
Further information:

This same problem occurs in both debug and release mode. I have reduced it to two essential lines of code:

#include &quot;fftw.h&quot;
void main()
{
fftw_plan p=fftw_create_plan(64, FFTW_FORWARD, FFTW_ESTIMATE);
}

The typical linker error in release mode is

MSVCRT.lib(MSVCRT.dll) : error LNK2005: _malloc already defined in LIBC.lib(malloc.obj)

I think the problem is that FFTW uses a multithreading library, LIBCMT.LIB, not MSVCRT.LIB, and these create two inconsistent versions of library functions. I guess I need to figure out how to prevent MSVCRT.LIB from being used and to use the other instead.

Still tracking this down.... I am a neophyte at this....

 
OK, I solved this problem.:) There is a C/C++ compiler option that controls which library is used:

/ML Single threaded
/MLd Single threaded debug

/MD Multiple threaded
/MDd Multiple threaded debug

The /ML's are the default. I needed to change to the /MD's manually so that my part of the code and the FFTW2st.lib part of the code are based on the same runtime library. Also, for debug compiles, it was necessary for me to add the following link option to avoid a conflict:

/nodefaultlib:&quot;MSVCRT.LIB&quot;

The /nodefaultlib:&quot;MSVCRT.LIB&quot; does not work with the Release build configuration - you get a great many undefined references. I'm not sure why the Release version requires MSVCRT.LIB but the debug version cannot tolerate it.

 
OK, I solved this problem.:) There is a C/C++ compiler option that controls which library is used:

/ML Single threaded
/MLd Single threaded debug

/MD Multiple threaded
/MDd Multiple threaded debug

The /ML's are the default. I needed to change to the /MD's manually so that my part of the code and the FFTW2st.lib part of the code are based on the same runtime library. Also, for debug compiles, it was necessary for me to add the following link option to avoid a conflict:

/nodefaultlib:&quot;MSVCRT.LIB&quot;

The /nodefaultlib:&quot;MSVCRT.LIB&quot; does not work with the Release build configuration - you get a great many undefined references. I'm not sure why the Release version requires MSVCRT.LIB but the debug version cannot tolerate it.

 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top