I am trying to compile a C program using the Intel icl compiler under MINGW/64. The program uses the following code:
#include <Userenv.h>
HANDLE process;
HANLDE token;
GetUserProfileDirectory(process, TOKEN_QUERY, &ptoken)
I am using the following compile command:
$ icl -g -DMINGW32 -DTESTMAIN user.c -o user -UserEnv.Lib
and I am linking against the UserEnv.Lib from the Microsoft SDK.
Intel(R) C++ Intel(R) 64 Compiler XE for applications running on Intel(R) 64, Version Microsoft (R) Incremental Linker Version 9.00.21022.08
-out:user.exe
user.obj
user.obj : error LNK2019: unresolved external symbol __imp_GetUserProfileDirectoryA referenced in function main
Any idea how to solve this problem?
SOLUTION:
The solution is to use
/link /c/Program\ Files/Microsoft\ SDKs/Windows/v6.0A/Lib/x64/UserEnv.Lib /c/Program\ Files/Microsoft\ SDKs/Windows/v6.0A/Lib/x64/A
I copied the file UserEnv.lib from the Microsoft SDK (x64, 6.0) into the current working directory and compiled the program with
$ icl test.c -DMINGW32 ./UserEnv.Lib
LNK2019: unresolved external symbol __imp_GetUserNameA referenced in function main test.obj : error LNK2019: unresolved external symbol __imp_OpenProcessToken referenced in function main test.obj : error LNK2019: unresolved external symbol –
and I am still getting the unresolved symbols.
Olaf
You need to add userenv.lib to your input libraries for the linker to see GetUserProfileDirectory().
EDIT: It's been a while since I've touched an Intel compiler, but IIRC you're supposed to use /link to introduce linker options:
$ icl test.c -DMINGW32 /link ./UserEnv.Lib
Related
The following simple program
#include <malloc.h>
int main(int argc, char **argv)
{
char* arr=malloc(10);
arr[10]='\0';
return 0;
}
builds fine with VC2019 16.8.2 in 32 bit dynamic linking
cl -Zi -fsanitize=address -MD clang_rt.asan_dynamic-i386.lib xx.c
and reports the memory error when running the program.
However when using the 64bit variant I get a linking error
> cl -Zi -fsanitize=address -MD clang_rt.asan_dynamic-x86_64.lib xx.c
Microsoft (R) C/C++ Optimizing Compiler Version 19.28.29336 for x64
Copyright (C) Microsoft Corporation. All rights reserved.
xx.c
Microsoft (R) Incremental Linker Version 14.28.29336.0
Copyright (C) Microsoft Corporation. All rights reserved.
/out:xx.exe
/debug
clang_rt.asan_dynamic-x86_64.lib
xx.obj
xx.obj : error LNK2019: unresolved external symbol __asan_shadow_memory_dynamic_address referenced in function main
xx.exe : fatal error LNK1120: 1 unresolved externals
Looking in the clang_rt.asan_dynamic-x86_64.lib with dumpbin the missing symbol appears.
Note that on both architectures static linking of the sample (without the _dynamic libs) works, but I need dynamic linking because of larger dependencies (Qt dlls).
Anyone stumbled across that already ?
Regards, Leo
turned out I need another link library for 64 bit in addition clang_rt.asan_dynamic_runtime_thunk-x86_64.lib
cl -MD -fsanitize=address clang_rt.asan_dynamic-x86_64.lib clang_rt.asan_dynamic_runtime_thunk-x86_64.lib xx.c
links the program correctly and brings up the sanitizer error after starting the program.
The page https://devblogs.microsoft.com/cppblog/asan-for-windows-x64-and-debug-build-support/ has a nice table which enumerates all the different build models and which asan libs are needed.
I have compiled 32-bit dll library and I have its source and header file. The library is somehow showing print dialog and allows me to print files. I've made 32-bit C# application, which calls printing function in dll and everything is nice.
However, now I need to recompile library to 64-bit (Recompiling my C# project is easy). Basicly I tried two methods.
First one was compiling from Visual's Studio Developer command prompt. This was first time compiling something using command line, so I googled what should I write. I was not attempting to specify 64-bit architecture, because I wanted to be sure that it is working. I used this command to build it.
cl /D_USRDLL /D_WINDLL printing.c User32.Lib WinSpool.Lib Gdi32.Lib ComDlg32.Lib /link /DLL /OUT:printing.dll
It made printing.dll for me, I tried to replace precompiled version I already had and I tried it using my C# app. Everything worked. So I wanted to compile it as 64-bit library. I googled and found out, that I have to use different cl.exe and link.exe located in Program Files\Microsoft Visual Studio 12.0\VC\bin\amd64. So I cd-ed to correct folder and wrote same command. I've got bunch (29) of "unresolved externals", I googled and found out that it is because I am trying to link 32-bit libraries. So I changed all *.Lib-s to C:\Program Files (x86)\Windows Kits\8.1\Lib\winv6.3\um\x64*.Lib", retried and still got some (16) unresolved extarnals. Here is the list
/out:printing.exe
/DLL
/OUT:D:\Temp\printing\printing.dll
printing.obj
"C:\Program Files (x86)\Windows Kits\8.1\Lib\winv6.3\um\x64\User32.Lib"
"C:\Program Files (x86)\Windows Kits\8.1\Lib\winv6.3\um\x64\WinSpool.Lib"
"C:\Program Files (x86)\Windows Kits\8.1\Lib\winv6.3\um\x64\Gdi32.Lib"
"C:\Program Files (x86)\Windows Kits\8.1\Lib\winv6.3\um\x64\ComDlg32.Lib"
Creating library D:\Temp\printing\printing.lib and object D:\Temp\printing\printing.exp
printing.obj : error LNK2019: unresolved external symbol __report_rangecheckfailure referenced in function RSS_PrintFile
printing.obj : error LNK2019: unresolved external symbol strcpy referenced in function RSS_PrintFileBez
printing.obj : error LNK2019: unresolved external symbol strcmp referenced in function RSS_PrintFileBez
printing.obj : error LNK2019: unresolved external symbol strlen referenced in function RSS_PrintFile
printing.obj : error LNK2019: unresolved external symbol __imp_CreateFileA referenced in function RSS_PrintFile
printing.obj : error LNK2019: unresolved external symbol __imp_ReadFile referenced in function RSS_PrintFile
printing.obj : error LNK2019: unresolved external symbol __imp_CloseHandle referenced in function RSS_PrintFile
printing.obj : error LNK2019: unresolved external symbol __imp_GlobalFree referenced in function RSS_PrintFile
printing.obj : error LNK2019: unresolved external symbol __imp_LocalAlloc referenced in function RSS_PrintFileBez
printing.obj : error LNK2019: unresolved external symbol __imp_LocalHandle referenced in function RSS_PrintFileBez
printing.obj : error LNK2019: unresolved external symbol __imp_LocalFree referenced in function RSS_PrintFileBez
printing.obj : error LNK2019: unresolved external symbol atoi referenced in function RSS_PrintFileBezFromTo
printing.obj : error LNK2001: unresolved external symbol __GSHandlerCheck
printing.obj : error LNK2019: unresolved external symbol __security_check_cookie referenced in function RSS_PrintFile
printing.obj : error LNK2019: unresolved external symbol __security_cookie referenced in function RSS_PrintFile
LINK : error LNK2001: unresolved external symbol _DllMainCRTStartup
D:\Temp\printing\printing.dll : fatal error LNK1120: 16 unresolved externals
I managed to get rid of 4 unresolved externals adding /GS- option to compiler, but I do not know how to fix rest and I could not find any help. So I decided to use Microsoft Visual Studio to build my libary.
I've created new C++ project, set it to be a DLL library, added source and header file, compiled (using standart settings, on 32-bit). I've got bunch of warnings like this one
'function' : incompatible types - from 'char *' to 'LPCWSTR'
and simmilars and one error
'strcpy': This function or variable may be unsafe. Consider using strcpy_s instead. To disable deprecation, use _CRT_SECURE_NO_WARNINGS. See online help for details.
So I #include _CRT_SECURE_NO_WARNINGS on first line of printing.c file. Hiting "Build" button then resulted in 1 successful and I got my printing.dll. I replaced printing.dll I've got from command line by this one and I tested dll using my C# app. Pressing print button brought "Select Printer and so" window (as before), but hitting print resulted in opening small window with some chinese text. However, I can easily build it as 64-bit.
I would like to ask what am I doing wrong, why I can not compile C library from command prompt and why Microsoft visual studio somehow makes DLL not working.
I tried to debug DLL library compiled using MVS, but I failed. I do not know which solution should I open (C# testing app, or C DLL solution) and what to do next. C# wont show me code from another solution and even if I up debuger in DLL solution to open C# application it produces error
Debugginng information for "app.exe" could not be found or does not match. Skipped loading symbols for NGen binary.
and even if I press "Continue debugging", any breakpoint says, that it wont be hit, because no symbols were loaded.
So Basicly
How do I get rid of "unresolved externals" errors while compiling as 64-bit using command line?
OR
How do I fix Microsoft Visual Studio to built working dll library (does not matter if 32-bit or 64bit)?
Ok. I've managed to fix this issue. I gave up trying to build 64-bit version using command line and focused on fixing issue about chinese chars. I went to Project -> Project Properties -> Configuration Properties -> C/C++ -> Command Line to see what compiler parameters are passed. Then I went back to command line, and added previously found parameters one by one and testing if dll works. When I added /D "UNICODE", the library stopped working.
This being said, adding #undef UNICODE or setting Configuration Properties -> General -> Project Defaults -> Character Set to Not Set fixed my issue and now I a able to compile my printing library for both x86 and x64 architectures.
I have successfully built Clang with Microsoft C++ and I'm trying to get it to compile a hello world test case; it gets as far as generating an object file, linking with the standard library being the remaining stumbling block:
hello-202520.o : error LNK2019: unresolved external symbol _printf referenced in function _main
LINK : error LNK2001: unresolved external symbol _mainCRTStartup
There are comments from previous years saying Clang doesn't yet do Windows linking at all, but I get the impression those are outdated, and indeed it does now seem to be able to generate Windows format object files:
clang -c hello.c
ren hello.o hello.obj
link hello.obj
... doesn't barf, so the file format seems to be correct, but still gets the unresolved external symbol errors. Likely guess is the Microsoft compiler tags its output object files with an indication of the standard library they need to be linked with whereas Clang doesn't, and eyeballing a hex dump of the respective object files seems to confirm this and gives a hint of the linker command line to use:
link /defaultlib:libcmt /defaultlib:oldnames hello.obj
I had high hopes by this stage but alas it still gives the same unresolved external symbol errors.
What am I still missing?
Turns out Clang was by default generating 32-bit code but I was using 64-bit MSC, and the leading _ on C symbols has been dropped with the move to x64, so specifying -m64 on the clang command line did the job.
I have written a C Program which calls the function, GetModuleInformation() which is defined in psapi.h
I am using Microsoft Visual Studio C++ command line compiler (cl.exe) for compiling and linking the program.
I have included the psapi.h header file:
#include <psapi.h>
when I try to compile using:
cl program.c
It generates the object file, however fails during the linking stage with the error:
program.obj : error LNK2019: unresolved external symbol _GetModuleInformation#16 ref
erenced in function _main
program.exe : fatal error LNK1120: 1 unresolved externalsprogram.obj : error LNK2019: unresolved external symbol _GetModuleInformation#16 ref
I also place the psapi.lib file in the same folder where the source code file (program.c) is placed, however even then I get the same error message as above.
How do I successfully link it using the command line compiler (cl.exe)?
Method 1
If you want to compile from the command line with cl.exe you can use the /link option to specify linker options :
cl /TC program.c /link psapi.lib
Method 2
The following pragma directive causes the linker to search in your source file for the psapi.lib library while linking .
#pragma comment( lib, "psapi.lib" )
Possible reason for your errors can be, if psapi.lib is missing in a list of additional libraries of linker.
To resolve this, use the following /LIBPATH option :
cl /TC program.c /link Psapi.Lib /LIBPATH:C:\MyLibFolder\
Where C:\MyLibFolder specifies a path to the folder, that contains your psapi.lib .
Also, you can try to set the proper /SUBSYSTEM option .
For a Console application use :
/SUBSYSTEM:CONSOLE
Solution to similar problem here .
Example on using the GetModuleInformation function :
#include <windows.h>
#include <stdio.h>
#include <psapi.h>
#pragma comment( lib, "psapi.lib" )
int main(void)
{
MODULEINFO minfo = {0};
GetModuleInformation( GetCurrentProcess(), GetModuleHandle( "psapi.dll" ), &minfo, sizeof(minfo) );
/* printf("%X", minfo.lpBaseOfDll); /* The load address of the module */
return 0;
}
The code has been tested on Windows 7 and XP .
The output from linking session is :
program.c
/out:program.exe
psapi.lib
/LIBPATH:C:\MyLibFolder\
/SUBSYSTEM:CONSOLE
/VERBOSE
program.obj
Starting pass 1
Processed /DEFAULTLIB:uuid.lib
Processed /DEFAULTLIB:LIBCMT
Processed /DEFAULTLIB:OLDNAMES
Searching libraries
Searching C:\MyLibFolder\psapi.lib:
Found _GetModuleInformation#16
Referenced in program.obj
Loaded psapi.lib(PSAPI.DLL)
Found __IMPORT_DESCRIPTOR_PSAPI
Referenced in psapi.lib(PSAPI.DLL)
Loaded psapi.lib(PSAPI.DLL)
Found __NULL_IMPORT_DESCRIPTOR
Referenced in psapi.lib(PSAPI.DLL)
Loaded psapi.lib(PSAPI.DLL)
...
If vsvars32.bat and all appropriate environment variables in your Visual Studio are set correctly the above linker options will produce a valid executable(.exe) file.
I'm trying to compile a c-file, cfile.c, which calls a subroutine in a fortran file, fortfile.f, and it's necessary for me to compile it on windows. The commands I'm using to do so are, in order:
icl /c /Qipo cfile.c
ifort /c /Qipo fortfile.f
icl cfile.obj fortfile.obj /Qipo
I use icl for linking because ifort seems to require the option nofor_main which is not available in windows. But when I do these commands, I get the following error:
ipo: error #11023: Not all components required for linking are present on command line
ipo_5220.obj: error LNK2019: unresolved external symbol _pythagoras_ referenced in function _main
Note that pythagoras is the subroutine called in fortran. Any ideas what's the matter?