Frustating VS 2005 LNK2020 error

[Gustavo L. Fabro]

Greetings!



I'm trying to compile my working VS 2003 solution under VS 2005 beta 1 and
all 16 dlls compiled just fine, except for one which is driving me crazy.



The error is, supposedly, an easy one. I get the traditional LNK2020 error:



------ Build started: Project: QIVProjectManager, Configuration: Debug
Win32 ------

Linking...

Creating library ..\VCLibDll/QIVProjectManager.lib and object
...\VCLibDll/QIVProjectManager.exp

ProjectTables.obj : error LNK2020: unresolved token (0A0003B7) "unsigned int
__cdecl strlen(char const *)" (?strlen@@$$J0YAIPBD@Z)

ProjectFileManagerTables.obj : error LNK2020: unresolved token (0A00094E)
"unsigned int __cdecl strlen(char const *)" (?strlen@@$$J0YAIPBD@Z)

ProjectDataBase.obj : error LNK2020: unresolved token (0A000465) "unsigned
int __cdecl strlen(char const *)" (?strlen@@$$J0YAIPBD@Z)

...\VCLibDll/QIVProjectManager.dll : fatal error LNK1120: 3 unresolved
externals

Build log was saved at
"file://c:\fontesusrb\QiCadVXAdriano\QiCad\VCObj\BuildLog.htm"

QIVProjectManager - 4 error(s), 0 warning(s)

========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========



Explaining the context:



- There is an unmanaged DLL, X, and it uses strlen()

- There is an unmanaged DLL, Y, that uses X

- And there is a managed DLL Z, that calls Y functions (statically,
adding .h and importing .lib)



Z is "QIVProjectManager.dll", which isn't linking. X and Y compile and link
just fine. They are all being built under debug mode.



I just don't know what else to do to solve this issue. I searched and tried
every single thing I found with no success at all:



- I am compiling all DLLs with the dynamic DLL CRT, debug mode
(/MDd). With this I believe I assure that there is no conflict in different
CRTs being used.

- I've read and applied the changes stated in
http://support.microsoft.com/?id=814472 for solving the mixed DLL loading
problem. That didn't change anything as far as these LNK2020 errors are
concerned.

- I've included and excluded many files from the linker
configuration setting with no success



Any clues as to how to solve this? Why isn't the linker finding the strlen()
function in msvcrtd.lib?



Thanks,



Gustavo L. Fabro

gustavo_fabro%removethis%@hotmail.com

 

[Gustavo L. Fabro]

I've run the linker using /VERBOSE as a parameter.

In this line I see it is loading MSVCRTD.LIB, and then, among other things,
it finds strlen in MSVCRTD library:

Searching C:\Arquivos de programas\Microsoft Visual Studio
8\VC\lib\MSVCRTD.lib:

....

Found _strlen
Referenced in libcpmtd.lib(xdebug.obj)
Loaded MSVCRTD.lib(MSVCR80D.dll)

The only other references I find of 'strlen' on the log file is when it
finishes pass 1:

Finished searching libraries
Finished pass 1
Search transition ?strcpy_s@@$$J0YAHPADIPBD@Z->_strcpy_s
Search transition ?malloc@@$$J0YAPAXI@Z->_malloc
Search transition ?strlen@@$$J0YAIPBD@Z->_strlen

and on the error message at the end:

ProjectTables.obj : error LNK2020: unresolved token (0A0003B7) "unsigned int
__cdecl strlen(char const *)" (?strlen@@$$J0YAIPBD@Z)

ProjectFileManagerTables.obj : error LNK2020: unresolved token (0A00094E)
"unsigned int __cdecl strlen(char const *)" (?strlen@@$$J0YAIPBD@Z)
ProjectDataBase.obj : error LNK2020: unresolved token (0A000465) "unsigned
int __cdecl strlen(char const *)" (?strlen@@$$J0YAIPBD@Z)
...\VCLibDll/QIVProjectManager.dll : fatal error LNK1120: 3 unresolved
externals


Does this tells something? Will the entire LOG file help?

My linking parameters are:

/VERBOSE /OUT:"..\VCLibDll/QIVProjectManager.dll" /INCREMENTAL /NOLOGO
/LIBPATH:"..\..\PlatformSDK\Lib" /LIBPATH:"c:\codebase"
/LIBPATH:"..\..\Libbuilder" /LIBPATH:"..\..\Persistence"
/LIBPATH:"..\..\QiReportBuilder" /LIBPATH:"..\..\QiDatabase"
/LIBPATH:"..\VCLibDll" /LIBPATH:"F:\Components\XceedZip\Dll Api" /DLL
/MANIFEST
/MANIFESTFILE:"c:\fontesusrb\QiCadVXAdriano\QiCad\VCLibDll\QIVProjectManager.dll.intermediate.manifest"
/NODEFAULTLIB:"nochkclr.obj" /INCLUDE:"__DllMainCRTStartup@12" /DEBUG
/ASSEMBLYDEBUG /PDB:"..\VCLibDll/QIVProjectManager.pdb" /SUBSYSTEM:WINDOWS
/IMPLIB:"..\VCLibDll/QIVProjectManager.lib" /MACHINE:X86 /FIXED:No
QIVDatabase.lib QIVLibrary.lib QIVPersistence.lib QIVReport.lib QIVCad.lib
QIVCommands.lib QIVConfig.lib QIVDwgDirect.lib QIVElements.lib QIVFields.lib
QIVForms.lib QIVGeneral.lib QIVPrinter.lib QIVProjectForms.lib
QIVSymbols.lib QIVTools.lib LZ32.lib kernel32.lib gdi32.lib user32.lib
Winspool.lib Advapi32.lib shell32.lib Comdlg32.lib kernel32.lib
libsmanifest.res

Thanks for any clues.

 

[Mihajlo Cvetanovic]

I'm trying to compile my working VS 2003 solution under VS 2005 beta 1 and
all 16 dlls compiled just fine, except for one which is driving me crazy.

ProjectTables.obj : error LNK2020: unresolved token (0A0003B7) "unsigned int
__cdecl strlen(char const *)" (?strlen@@$$J0YAIPBD@Z)

ProjectFileManagerTables.obj : error LNK2020: unresolved token (0A00094E)
"unsigned int __cdecl strlen(char const *)" (?strlen@@$$J0YAIPBD@Z)

I don't know anything about VS2005, but shouldn't the only argument of
strlen be declared as "const char *" instead of "char const *"?

 

[Severian [MVP]]

Greetings!



I'm trying to compile my working VS 2003 solution under VS 2005 beta 1 and
all 16 dlls compiled just fine, except for one which is driving me crazy.



The error is, supposedly, an easy one. I get the traditional LNK2020 error:



------ Build started: Project: QIVProjectManager, Configuration: Debug
Win32 ------

Linking...

Creating library ..\VCLibDll/QIVProjectManager.lib and object
..\VCLibDll/QIVProjectManager.exp

ProjectTables.obj : error LNK2020: unresolved token (0A0003B7) "unsigned int
__cdecl strlen(char const *)" (?strlen@@$$J0YAIPBD@Z)

ProjectFileManagerTables.obj : error LNK2020: unresolved token (0A00094E)
"unsigned int __cdecl strlen(char const *)" (?strlen@@$$J0YAIPBD@Z)

ProjectDataBase.obj : error LNK2020: unresolved token (0A000465) "unsigned
int __cdecl strlen(char const *)" (?strlen@@$$J0YAIPBD@Z)

<snip>

It looks to me like strlen is somehow getting declared as a C++
function, rather than a C function. Did one of our header files
declare it explicitly, rather than including <string.h>?

I have not worked with VC 2005, so maybe this is normal in that
enviroment, but I'm certainly used to strlen having C linkage, for
which the symbol would be "_strlen".

I will begin testing VC 2005 Beta 2 sometime in the next few days; If
I learn anything I will return to this thread and post more info.

 

[Severian [MVP]]

I don't know anything about VS2005, but shouldn't the only argument of
strlen be declared as "const char *" instead of "char const *"?

The name "demangler" reports it that way. AFAIK, strlen should have C
linkage, with the link symbol name of simply "_strlen".

 

[Gustavo L. Fabro]

Creating library ..\VCLibDll/QIVProjectManager.lib and object

<snip>

It looks to me like strlen is somehow getting declared as a C++
function, rather than a C function. Did one of our header files
declare it explicitly, rather than including <string.h>?

I have not worked with VC 2005, so maybe this is normal in that
enviroment, but I'm certainly used to strlen having C linkage, for
which the symbol would be "_strlen".

I will begin testing VC 2005 Beta 2 sometime in the next few days; If
I learn anything I will return to this thread and post more info.

Thanks for the replies. I just found out what was happening and got a
solution (if it's my mistake) or workaround(linker's fault) for it.

The problem was a "#pragma intrinsic(strlen)" option in one cpp file from
the unmanaged DLL.

Even though the compiler was instructed not to generate intrinsic functions
(the /Oi was NOT set and optimizations were disabled), this somehow messed
things up on the managed DLL that used it.

The solution was to include a "#pragma function(strlen)" after the
"#include"s section of the CPP files whose corresponding OBJs were giving
the LNK2020 error. This directive tells the compiler to call the library
function instead of trying to inline it, and solves the "Unresolved
External" error.

Why did that happen, though, is still mysterious...

Fabro
gustavo_fabro%removethis%@hotmail.com