strange linker error (for me at least)

[rik]

I'm porting an old application to unicode atm and thereby the linker is bugging me.

I'm on win2000, using dev-cpp 4.9.9.2

I made a simple project to be able to show whats going on, if I dont define UNICODE nor _UNICODE, my compile log looks as follows

Compiler: Default compiler
Building Makefile: "C:\cpp_projekte\fenriz\Makefile.win"
Führt make... aus
make.exe -f "C:\cpp_projekte\fenriz\Makefile.win" all
g++.exe -c main_.cpp -o main_.o -I"C:/Dev-Cpp/lib/gcc/mingw32/3.4.2/include" -I"C:/Dev-Cpp/include/c++/3.4.2/backward" -I"C:/Dev-Cpp/include/c++/3.4.2/mingw32" -I"C:/Dev-Cpp/include/c++/3.4.2" -I"C:/Dev-Cpp/include" -Wformat -Wall -Werror

g++.exe main_.o cFilehandling.o -o "Demoproject.exe" -L"C:/Dev-Cpp/lib" -s

Ausführung beendet
Kompilierung erfolgreich

and here the one with UNICODE + _UNICODE defined

Compiler: Default compiler
Building Makefile: "C:\cpp_projekte\fenriz\Makefile.win"
Führt make clean aus
rm -f main_.o cFilehandling.o Demoproject.exe

g++.exe -c main_.cpp -o main_.o -I"C:/Dev-Cpp/lib/gcc/mingw32/3.4.2/include" -I"C:/Dev-Cpp/include/c++/3.4.2/backward" -I"C:/Dev-Cpp/include/c++/3.4.2/mingw32" -I"C:/Dev-Cpp/include/c++/3.4.2" -I"C:/Dev-Cpp/include" -Wformat -Wall -Werror

g++.exe -c cFilehandling.cpp -o cFilehandling.o -I"C:/Dev-Cpp/lib/gcc/mingw32/3.4.2/include" -I"C:/Dev-Cpp/include/c++/3.4.2/backward" -I"C:/Dev-Cpp/include/c++/3.4.2/mingw32" -I"C:/Dev-Cpp/include/c++/3.4.2" -I"C:/Dev-Cpp/include" -Wformat -Wall -Werror

g++.exe main_.o cFilehandling.o -o "Demoproject.exe" -L"C:/Dev-Cpp/lib" -s

main_.o(.text+0x53):main_.cpp: undefined reference to `cFilehandling::SetLastFileName(wchar_t*)'
collect2: ld returned 1 exit status

make.exe: *** [Demoproject.exe] Error 1

Ausführung beendet

//main.cpp

define UNICODE

define _UNICODE

include <windows.h>

include <cstdlib>

include <tchar.h>

include "cFilehandling.h"

int main(int argc, char *argv[])
{

cFilehandling a;
a.SetLastFileName(TEXT("Test"));
system("PAUSE");
return EXIT_SUCCESS;

}

// cFilehandling.cpp

include <windows.h>

include "cFilehandling.h"

VOID cFilehandling::SetLastFileName(TCHAR* filename)
{
lstrcpy(f->szLastFileName, filename);
}

cFilehandling::cFilehandling()
{

lstrcpy(f->szLastFileName, TEXT(""));

}

// cFilehandling.h

ifndef cFILEHANDLING_H

define cFILEHANDLING_H

include <tchar.h>

include <windows.h>

class cFilehandling
{
struct File
{
TCHAR szLastFileName[MAX_PATH];
}file;

File* f;

public:
cFilehandling();

VOID SetLastFileName(TCHAR* filename);

};

endif // _cFILEHANDLING_H

any ideas how to get around this?

thanks in advance,

rik

[Anonymous]

The problem was that in the original code you defined _UNICODE in main.cpp but not in cFilehandling.cpp. In teh second you appear to have included it in the header, so it was defined in both modules - although here you also seem to have changed <tchar.h> for <cstdlib> which is odd - perhpas you typed it instead of copy&paste?

Either way this is not a good solution, you always run the risk of linking a module not built for Unicode. The simple way to ensure that _UNICODE is globally defined is to specify it as a command line argument: -D_UNICODE. (then Rebuild all at least once after setting).

Clifford

[rik]

Thank you Clifford for the command-line tip, that really sounds reasonable ;)
I didn't change <tchar.h> I simply removed it completely, since I did read that TCHAR is already defined in WINNT.H if one includes <windows.h> and since I didn't use other string-handling functions in this case I just skipped it.
The <cstdlib> was moved from main_.cpp into the header file I think.

rik

[rik]

ok, seems like I found a solution, I still don't understand why it is working now, but I changed the location/order of the included header files and the linker error was gone.

ifndef cFILEHANDLING_H

define cFILEHANDLING_H

define _UNICODE

define UNICODE

include <windows.h>

include <cstdlib>

class cFilehandling
{

..........
// I did remove the includes from the other files except for #include "cFilehandling.h"

rik

[rik]

oops, just noticed that I did miss something in the code above: f = &file;
but anyway, I would be glad if someone would be able to alight me to the correct linking order in such a case. Thank you!