c++linker-errorstdm-mingwtdm-gcc

TDM-GCC raises error: Undefined reference to a method I never called


This is with the compiler that comes with Dev-C++ when run on Windows 7, "TDM-GCC 4.9.2 64-bit Release". The same thing happens with the 64-bit version as well. The "add the following flags when calling the linker" in "Compiler Options" is set to -static-libgcc -lws2_32, and "add the following flags when calling the compiler" is std=c++11.

Unfortunately, I can't get much more information than that because this is a very, very locked down computer.

Once I get home, I'll test it there and edit in any new information.

A test file:

#include <windows.h>
#include <psapi.h>
#include <iostream>

int main() {
    HANDLE h = GetCurrentProcess();
    TCHAR name[100];
    GetProcessImageFileName(h, name, 100);
    std::cout << "Name is " << std::endl;
}

When compiled, it gives the following error:

C:\Users\[REDACTED]\AppData\Local\Temp\ccQz3L9P.o:test.cpp:(.text+0x2f): undefined reference to `GetProcessImageFileNameA'

As best as I can tell, it's calling GetProcessImageFileNameA instead of GetProcessImageFileName because of a #define in psapi.h:

#define GetProcessImageFileName __MINGW_NAME_AW(GetProcessImageFileName)

__MINGW_NAME_AW(func) is #defined in _mingw_unicode.h as func##A, which if I understand it correctly is where the new method name is coming from.

Back in psapi.h, DWORD WINAPI GetProcessImageFileNameA(HANDLE, LPSTR, DWORD); is declared, but I haven't found its definition anywhere, and Dev-C++ can't either. I'm fairly certain that's the problem.

How can I fix it? I'm open to anything, up to and including switching compilers or IDEs, as long as I can put whatever I use on a flash drive and carry it around with as little annoyance as possible, and that the end result doesn't require admin privileges to run.


Solution

  • GetProcessImageFileName is a windows API function and you need to link in the correct library to get to it.

    It is defined as a macro to be either GetProcessImageFileNameA or GetProcessImageFileNameW depending whether you are compiling "wide" or "narrow".

    The Win32 API has Unicode and ascii versions of each function (at least the functions that take strings). In general, the ascii version converts the characters to Unicode and calls the other implantation internally.