yang686526

link error: new and delete already defined
link error: new and delete already defined
environment:
windows xp pro
visual studio .net 2003
dwgdirect 1.11.01.00
i'm having some trouble trying to link in the dwgdirect libraries on the release build. my code compiles okay, but when it tries to link i get the following errors (i switched on verbose linking to get more details):
searching c:\program files\microsoft visual studio .net 2003\vc7\atlmfc\lib\nafxcw.lib:
nafxcw.lib(afxmem.obj) : error lnk2005: "void * __cdecl operator new(unsigned int)" (??2@yapaxi@z) already defined in dd_vc2003mt_alloc.lib(odalloc.obj)
nafxcw.lib(afxmem.obj) : error lnk2005: "void __cdecl operator delete(void *)" (??3@yaxpax@z) already defined in dd_vc2003mt_alloc.lib(odalloc.obj)
nafxcw.lib(afxmem.obj) : error lnk2005: "void * __cdecl operator new[](unsigned int)" (??_u@yapaxi@z) already defined in dd_vc2003mt_alloc.lib(odalloc.obj)
nafxcw.lib(afxmem.obj) : error lnk2005: "void __cdecl operator delete[](void *)" (??_v@yaxpax@z) already defined in dd_vc2003mt_alloc.lib(odalloc.obj)
i don't get the errors on the debug build...
any help here would be much appreciated!
many thanks,
jonathan.
did you try explicitly exclude from link "nafxcw.lib"?
just tried excluding "nafxcw.lib" from the build and it comes up with thousands of unresolved externals. seems to be a fairly critical library - i don't think i can do without it.
any other ideas?
jonathan.
i see you are using lib version of crt
is that critical for you app?
in our samples we use msvcrt.dll
(/md compiler switch)
we use the /mt switch rather than the /md so that our customers don't have to have msvcrt.dll on their machines. it saves a lot of trouble making sure they have the right version of the .dll.
it looks like it would work if i built it with the /md switch (since the debug one works and that was built with the /mdd switch), but surely i ought to be able to statically link in the library version of crt (with /mt) and then link in dd_vc2003mt_alloc.lib? doesn't the mt in the library filename mean exactly that - that it's designed to link with the /mt compiler switch?
well, perhaps it is a bug in dd.
you may try to use /force:multiple linker option to build the project,
and we will try to fix the bug to the next release.
okay then. thanks for your help.
quote:
originally posted by wvk
well, perhaps it is a bug in dd.
you may try to use /force:multiple linker option to build the project,
and we will try to fix the bug to the next release.
i get similar compile problems:
code:
linking...
nafxcwd.lib(afxmem.obj) : error lnk2005: "void * __cdecl operator new(unsigned int)" (??2@yapaxi@z) already defined in libcmtd.lib(new.obj)
nafxcwd.lib(afxmem.obj) : error lnk2005: "void __cdecl operator delete(void *)" (??3@yaxpax@z) already defined in libcpmtd.lib(delop.obj)
debug/seq2dwg.exe : fatal error lnk1169: one or more multiply defined symbols found
error executing link.exe.
seq2dwg.exe - 3 error(s), 0 warning(s)
you can also leave out dd_alloc, and just link in your own versions of the odrxxxx functions that are contained in there:
extern "c" {
allocdll_export void* odrxalloc(size_t s)
{
return ::malloc(s);
}
allocdll_export void* odrxrealloc(void* p, size_t new_size, size_t /*old_size*/)
{
return ::realloc(p, new_size);
}
allocdll_export void odrxfree(void* p)
{
::free(p);
}
} // extern "c"

all seems abit complicated for me i not understand why one 1.10 project compiles and not this new skeleton one...
fixed it!
firstly, i reverted to 1.10 as i saw no real need from my point of view to use version 1.11.
but as you guessed, i got the ugly new/delete already defined stuff spoiling everything.
i was not happy that a existing application was working ok.
what i ened up doing was deleting the dsw file and editing the dsp file and moving all the exxxxx files so that they were below my main program files.
then i double-clicked the dsp file and it created a new dsw file for me.
then i deleted everything in the debug/release folders and did a full re-build for debug/release.
they compile with no errors. you see, it compiles the mai app class file before the ex files get compiled.
0 errors for using /mt and /mtd...
maybe, i could have stuck with 1.11 using this approach, but i have played so much with it now, i want to get on.
if anyone is still having their problem, please try this idea, because if it works for you in release using /mt and 1.11, i just might move up to this library.
i hope this detail is on help.
andrew
any luck
jonathan,
did you find the solution for your problem...
hello, this is my little contribution:
i've tried the solution ajtruckle suggested, but it doesn´t work to me with dd111, and i'm sure i did what ajtruckle said.
i've rebuild my project with the link setting force file output on, i've obtained a new brand .exe file but in my code there is a call to oddbdatabase::loadlinetypefile(...) that were working fine with dd109 and doesn't work now, it launches an exception with an error description "invalid input". i suspect this is due to the link setting but obviously i'm not sure.
i've tried a possible solution i read in a microsoft knowledge base article, consisting of putting my affected library (nafxcw.lib) in the "ignore libraries" edit box of link settings and putting the same library at first place in the "object/library" one. it didn't work.
i'm looking for new information but perhaps this is a dd bug as wvk said in this thread, ¿is it a bug or not?.
i'd like to try the workaround that suggested also in this thread, but i'd need some help in order to implement it.
quote:
originally posted by suaser
i've rebuild my project with the link setting force file output on, i've obtained a new brand .exe file but in my code there is a call to oddbdatabase::loadlinetypefile(...) that were working fine with dd109 and doesn't work now, it launches an exception with an error description "invalid input". i suspect this is due to the link setting but obviously i'm not sure.
well, it could be due to the link option, but it is highly improbable,
to make sure, you may link with dll version of msvcrt (/md compiler option),
and check whether this error persists.
quote:
i'd like to try the workaround that suggested also in this thread, but i'd need some help in order to implement it.
it is really the only correct way to solve this problem in mt build -
do not link to dd_alloc.lib, provide your own fuctions instead as neil wrote
(simply copy/paste the code, somewhere in your application)
no i haven't solved the problem yet. we don't need to release right now, so i can just do the development with the debug version and wait for the next library release which will hopefully fix the problem.
it has nothing to do with the link order as i've tried forcing the link order both ways (ie. nafxcw first, dd_alloc second and then dd_alloc first, nafxcw second).
i'm sure neil's solution would work, but i have no pressing need to use a workaround right now.