I am new to Windows driver development and minifilters and I am trying to build the nullFilter sample using command line tools.
So I added #pragma comment(lib, "FltMgr.lib") to the .c file and issued the following commands successfully:
cl.exe /nologo /Fo../../bin\filter.obj /c filter.c /D _AMD64_
rc.exe /nologo /Fo../../bin\filter.res filter.rc
However, when I try to create the sys file:
link.exe /nologo /DRIVER:WDM /out:../../bin\filter.sys ../../bin\filter.obj ../../bin\filter.res
LINK : error LNK2001: unresolved external symbol NtProcessStartup
../../bin\filter.sys : fatal error LNK1120: 1 unresolved externals
I am using VS2012 Express and WDM8. My LIB environment variable is:
C:\Program Files (x86)\Windows Kits\8.0\Lib\win8\um\x64;C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\lib\amd64;C:\Program Files (x86)\Windows Kits\8.0\Lib\win8\km\x64;
What am I doing wrong? Am I missing something?
NtProcessStartup function is to driver development what 'main' is for regular C programs. In other words, it is the program entry function that you need to provide yourself. See the article here for an introduction and explanation of this function. You can overrule the name of the startup function by using the -entry linker option. Setting '-entry:DriverEntry' is a common practice for driver development.
Related
I have an exe written in C (not C++ or C#) to call a dll. It compiles with Clang and I'm linking it from the Visual Studio command line using link.exe. This build is on Windows 7. My command string is:
link.exe SxSv.obj /nologo /subsystem:console /MACHINE:X64 /LIBPATH:"C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Lib\x64\" /OUT:SxSv.exe kernel32.lib
Link.exe gives me these errors:
SxSv.obj : error LNK2019: unresolved external symbol __imp_LoadLibraryA referenced in function WinMain
SxSv.obj : error LNK2019: unresolved external symbol __imp_GetProcAddress referenced in function WinMain
SxSv.obj : error LNK2019: unresolved external symbol __imp_FreeLibrary referenced in function WinMain
SxSv.obj : error LNK2019: unresolved external symbol __stdio_common_vsprintf referenced in function _vsnprintf_l
LINK : error LNK2001: unresolved external symbol mainCRTStartup
C:\Program Files (x86)\Windows Kits\10\lib\10.0.17763.0\um\x86\uuid.lib : warning LNK4272: library machine type 'x86' conflicts with target machine type 'x64'
SxSv.exe : fatal error LNK1120: 5 unresolved externals
The problem seems to be this line:
/LIBPATH:"C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Lib\x64\"
and I think the problem is the Windows SDK that is installed. This computer has Visual Studio 2017 CE installed.
My questions are:
It looks like there is only one SDK for Windows 7, released in 2010. Where would I expect to see it if it is installed?
Can I use it to link a 64-bit exe?
3, There are a lot of uuid.lib files installed on this Windows 7 box. Which one would I use for Windows 7 for a 64-bit exe?⌈
I am doing this from the Visual Studio Developer command line, not from the IDE.
Thanks for any help.
EDIT: the question suggested as the duplicate of this one is very helpful but it's not the complete solution to this problem as it does not explain what libraries to link to. The comment below by Hans Passant helps best. First I will transfer this project to Visual Studio and go from there to find the right libraries to link this to.
I'm trying to build paho_mqtt.c on Windows X86 (64-bit). I'm using Visual Studio Community 2013. Its a supported configuration.
To build paho_mqtt.c for 64-bit, one needs OpenSSL compiled for Windows 64-bit. To build OpenSSL I found I needed a new version of Active Perl. I then used the following commands to build OpenSSL:
perl Configure -no-asm VC-WIN64A
nmake
nmake test
All the tests worked so I have believe I have working SSL/TLS libraries.
When building MQTT paho it couldn't find the ssl.h. I used the trick on this page listed below to set the environment variables so msbuild would get the include path from the environment variables:
Adding additional library and include paths when compiling from command line
That worked and paho found ssl.h.
Next msbuild of paho.mqtt.c could not find libeay32 / ssleay32.dll. First I used the trick from above again so msbuild would search the correct directory for the openssl libraries. Although the new libraries work, the library names are different. I used the information in 2) on Compiling OpenSSL for Windows, Linux, and Macintosh and I did the following:
cp libssl.lib libeay32.lib
cp libcrypto.lib ssleay32.lib
This is questionable I know, but it appears to have worked; that is, the link command that was failing now runs without warning or error. But it might have just deferred any unresolved symbol problems until later.
msbuild is failing later when trying to link an executable (shown at the bottom of this post). msbuild is complaining it cannot resolve the MQTTClient_* funcitons/symbols (e.g. MQTTClient_connect). Those functions are all in MQTTClient.c, and msbuild built MQTTClient.obj without emitting any errors.
My questions revolve around "what is the real problem?":
Is the problem with MQTTClient.obj:
maybe it is not included in the link command?
or maybe the symbols are not in the object file?
Is the problem that I renamed the libraries?
msbuild is not reporting that it cannot find the MQTTClient.obj.
If the problem is with the openssl libraries I expect it would report some openssl symbols are not found.
On linux I would use nm -g to see whether the undefined symbols are in the MQTT_Client.obj. How do I verify this in Windows?
Thanks for any help you can provide,
Link:
C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\BIN\amd64\link.exe /ERRORREPORT:QUEUE /OUT:"C:\Users\don\paho.mqtt.c\Windows Build\x64\Release\paho-cs-pub.exe" /INCREMENTAL:NO /NOLOGO /LIBPA
TH:"C:\Users\don\paho.mqtt.c\Windows Build\\x64\Release" "paho-mqtt3a.lib" kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc3
2.lib odbccp32.lib /MANIFEST /MANIFESTUAC:"level='asInvoker' uiAccess='false'" /manifest:embed /DEBUG /PDB:"C:\Users\don\paho.mqtt.c\Windows Build\x64\Release\paho-cs-pub.pdb" /SUBSYSTEM:CONSOLE /O
PT:REF /OPT:ICF /LTCG /TLBID:1 /DYNAMICBASE /NXCOMPAT /IMPLIB:"C:\Users\don\paho.mqtt.c\Windows Build\x64\Release\paho-cs-pub.lib" /MACHINE:X64 x64\Release\paho_cs_pub.obj
paho_cs_pub.obj : error LNK2001: unresolved external symbol MQTTClient_create [C:\Users\don\paho.mqtt.c\Windows Build\stdoutsuba\stdoutsuba.vcxproj]
paho_cs_pub.obj : error LNK2001: unresolved external symbol MQTTClient_yield [C:\Users\don\paho.mqtt.c\Windows Build\stdoutsuba\stdoutsuba.vcxproj]
paho_cs_pub.obj : error LNK2001: unresolved external symbol MQTTClient_setCallbacks [C:\Users\don\paho.mqtt.c\Windows Build\stdoutsuba\stdoutsuba.vcxproj]
paho_cs_pub.obj : error LNK2001: unresolved external symbol MQTTClient_disconnect [C:\Users\don\paho.mqtt.c\Windows Build\stdoutsuba\stdoutsuba.vcxproj]
paho_cs_pub.obj : error LNK2001: unresolved external symbol MQTTClient_publish [C:\Users\don\paho.mqtt.c\Windows Build\stdoutsuba\stdoutsuba.vcxproj]
paho_cs_pub.obj : error LNK2001: unresolved external symbol MQTTClient_destroy [C:\Users\don\paho.mqtt.c\Windows Build\stdoutsuba\stdoutsuba.vcxproj]
paho_cs_pub.obj : error LNK2001: unresolved external symbol MQTTClient_connect [C:\Users\don\paho.mqtt.c\Windows Build\stdoutsuba\stdoutsuba.vcxproj]
C:\Users\don\paho.mqtt.c\Windows Build\x64\Release\paho-cs-pub.exe : fatal error LNK1120: 7 unresolved externals [C:\Users\don\paho.mqtt.c\Windows Build\stdoutsuba\stdoutsuba.vcxproj]
I have been trying to follow the instructions at http://llvm.org/docs/GettingStartedVS.html#an-example-using-the-llvm-tool-chain, but I run into errors at the linking stage. For some reason, I can compile the "hello world" program all the way to an .exe inside the Visual Studio GUI, but when I run the compiler (either clang or cl) from the command line, I get strange errors. I can create .obj objects just fine, but linking produces errors like the following:
link /DEFAULTLIB:libcmt /VERBOSE hello.obj
Microsoft (R) Incremental Linker Version 12.00.31101.0
Copyright (C) Microsoft Corporation. All rights reserved.
Starting pass 1
Searching libraries
Searching C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\LIB\libcmt.lib:
Finished searching libraries
Finished pass 1
Unused libraries:
C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\LIB\libcmt.lib
hello.obj : error LNK2019: unresolved external symbol printf referenced in function main
LINK : error LNK2001: unresolved external symbol mainCRTStartup
hello.exe : fatal error LNK1120: 2 unresolved externals
For some reason, it is ignoring the specified library and is unable to locate the relevant libraries for linking. How can I get the linker to resolve the symbols properly?
I've been trying to ressurect a XP-era .dll that uses Microsoft's Uniscribe, prossible VCL and other artifacts to do some transliteration. It was compiled at the time with some Borland toolchain and the project i was handed includes .res files from Visual Studio, .mrt and .mbt files which also seem to be GUI-related, .ide files which are Borland C++ Project files, .dsw Turbo C Context files (opening 'em in a text editor - they could also be VC6 files... shuders), .bpr BCB.04.04 / BCB IDE files, .dfm font-related files and .bpg BWS.01 files. I feel like a digital Indiana Jones, minus the whip and dust makes me sneeze.
I got a Borland toolchain from Embarcadero and was using Code::Blocks, only somewhere among the line -Weverything gets into the compiler arguments, which the Borland doesn't like.
LLVM's Clang currently barfs on winnt.h (which i'd rather not edit), on stuff like
\um\winnt.h:1341:1: error: C++ requires a type specifier for all declarations
Visual Studio's compiler barfs on something else entirely (didn't bother with it much, though) and i don't remember where did MinGW/GCC stop.
I've had to fiddle with includes and libs (mostly the ones from Embarcadero's include\ and lib) and compiler flags (currently _NO_VCL _MSC_VER=1200 BUILD_DLL) on account of a bunch or different errors and won't even bother with the warnings. Using the cmd line to compile this project (with one of the .bpr files and Embarcadero's documentation as reference) i managed to compile an .obj with this:
"C:\path\to\bcc32.exe" -w -tWM -tWD -y -vi- -v -a8 -r- -Od -D_NO_VCL -D_MSC_VER=1200
-I"C:\path\to\include\windows\crtl"
-I"C:\path\to\include\windows\vcl"
-I"C:\path\to\include\windows\rtl"
-I"C:\path\to\baseProjectDir"
-I"C:\path\to\baseProjectDir\subDir"
-oobj\Debug\myFile.obj -c ..\file1.cpp ..\subDir\file2.cpp ..\subDir\file3.cpp ..\subDir\file4.cpp
Yay. The fun continues when i try linking:
"C:\path\to\ILINK32.EXE" /aa /Tpd /x /Gn /Gi /q
/L"C:\path\to\baseProjectDir;C:\path\to\baseProjectDir\subDir;C:\path\to\lib\win32\debug;C:\path\to\lib\win32\release"
"C:\path\to\myFile.obj"
i get:
Error: Unresolved external '__turboFloat' referenced from root
Error: Unable to perform link
Googlefu tells me this is some sort of Borland vendor lock-in thing, so i changed my link line to:
"C:\path\to\ILINK32.EXE" /aa /Tpd /x /Gn /Gi /q
/L"C:\path\to\baseProjectDir;C:\path\to\baseProjectDir\subDir;C:\path\to\lib\win32\debug;C:\path\to\lib\win32\release"
"C:\path\to\lib\win32\release\c0d32.obj" "C:\path\to\myFile.obj"
...and now it really hits the fan:
Error: Unresolved external '__dbk_fcall_wrapper' referenced from C:\PROGRAM FILES (X86)\EMBARCADERO\STUDIO\17.0\LIB\WIN32\RELEASE\C0D32.OBJ
Error: Unresolved external 'GetVersion' referenced from C:\PROGRAM FILES (X86)\EMBARCADERO\STUDIO\17.0\LIB\WIN32\RELEASE\C0D32.OBJ
Error: Unresolved external '__ErrorMessage' referenced from C:\PROGRAM FILES (X86)\EMBARCADERO\STUDIO\17.0\LIB\WIN32\RELEASE\C0D32.OBJ
Error: Unresolved external '___CRTL_DLL_Lock' referenced from C:\PROGRAM FILES (X86)\EMBARCADERO\STUDIO\17.0\LIB\WIN32\RELEASE\C0D32.OBJ
Error: Unresolved external '___CRTL_VCL_Init' referenced from C:\PROGRAM FILES (X86)\EMBARCADERO\STUDIO\17.0\LIB\WIN32\RELEASE\C0D32.OBJ
Error: Unresolved external '___CRTL_MEM_UseBorMM' referenced from C:\PROGRAM FILES (X86)\EMBARCADERO\STUDIO\17.0\LIB\WIN32\RELEASE\C0D32.OBJ
Error: Unresolved external '___CRTL_VCLLIB_Linkage' referenced from C:\PROGRAM FILES (X86)\EMBARCADERO\STUDIO\17.0\LIB\WIN32\RELEASE\C0D32.OBJ
Error: Unresolved external '__ExceptInit' referenced from C:\PROGRAM FILES (X86)\EMBARCADERO\STUDIO\17.0\LIB\WIN32\RELEASE\C0D32.OBJ
Error: Unresolved external '__pRawDllMain' referenced from C:\PROGRAM FILES (X86)\EMBARCADERO\STUDIO\17.0\LIB\WIN32\RELEASE\C0D32.OBJ
Error: Unresolved external '__startupd' referenced from C:\PROGRAM FILES (X86)\EMBARCADERO\STUDIO\17.0\LIB\WIN32\RELEASE\C0D32.OBJ
Error: Unresolved external '__free_heaps' referenced from C:\PROGRAM FILES (X86)\EMBARCADERO\STUDIO\17.0\LIB\WIN32\RELEASE\C0D32.OBJ
Error: Unresolved external '___CRTL_VCL_Exit' referenced from C:\PROGRAM FILES (X86)\EMBARCADERO\STUDIO\17.0\LIB\WIN32\RELEASE\C0D32.OBJ
Error: Unresolved external '___CRTL_DLL_Unlock' referenced from C:\PROGRAM FILES (X86)\EMBARCADERO\STUDIO\17.0\LIB\WIN32\RELEASE\C0D32.OBJ
Error: Unresolved external '__GetExceptDLLinfoInternal' referenced from C:\PROGRAM FILES (X86)\EMBARCADERO\STUDIO\17.0\LIB\WIN32\RELEASE\C0D32.OBJ
Error: Unresolved external 'HeapAlloc' referenced from C:\PROGRAM FILES (X86)\EMBARCADERO\STUDIO\17.0\LIB\WIN32\RELEASE\C0D32.OBJ
Error: Unresolved external '___CRTL_TLS_SetValue' referenced from C:\PROGRAM FILES (X86)\EMBARCADERO\STUDIO\17.0\LIB\WIN32\RELEASE\C0D32.OBJ
Error: Unresolved external '___CRTL_TLS_InitThread' referenced from C:\PROGRAM FILES (X86)\EMBARCADERO\STUDIO\17.0\LIB\WIN32\RELEASE\C0D32.OBJ
Error: Unresolved external 'GetProcessHeap' referenced from C:\PROGRAM FILES (X86)\EMBARCADERO\STUDIO\17.0\LIB\WIN32\RELEASE\C0D32.OBJ
Error: Unresolved external 'HeapFree' referenced from C:\PROGRAM FILES (X86)\EMBARCADERO\STUDIO\17.0\LIB\WIN32\RELEASE\C0D32.OBJ
Error: Unresolved external '___CRTL_TLS_ExitThread' referenced from C:\PROGRAM FILES (X86)\EMBARCADERO\STUDIO\17.0\LIB\WIN32\RELEASE\C0D32.OBJ
Error: Unresolved external '___CRTL_TLS_Free' referenced from C:\PROGRAM FILES (X86)\EMBARCADERO\STUDIO\17.0\LIB\WIN32\RELEASE\C0D32.OBJ
Error: Unresolved external '___CRTL_TLS_Alloc' referenced from C:\PROGRAM FILES (X86)\EMBARCADERO\STUDIO\17.0\LIB\WIN32\RELEASE\C0D32.OBJ
Error: Unresolved external 'DllEntryPoint' referenced from C:\PROGRAM FILES (X86)\EMBARCADERO\STUDIO\17.0\LIB\WIN32\RELEASE\C0D32.OBJ
Error: Unresolved external '__argv_expand_ptr' referenced from C:\PROGRAM FILES (X86)\EMBARCADERO\STUDIO\17.0\LIB\WIN32\RELEASE\C0D32.OBJ
Error: Unresolved external '__wargv_expand_ptr' referenced from C:\PROGRAM FILES (X86)\EMBARCADERO\STUDIO\17.0\LIB\WIN32\RELEASE\C0D32.OBJ
Error: Unresolved external '__handle_setargv' referenced from C:\PROGRAM FILES (X86)\EMBARCADERO\STUDIO\17.0\LIB\WIN32\RELEASE\C0D32.OBJ
Error: Unresolved external '__handle_exitargv' referenced from C:\PROGRAM FILES (X86)\EMBARCADERO\STUDIO\17.0\LIB\WIN32\RELEASE\C0D32.OBJ
Error: Unresolved external '__handle_wsetargv' referenced from C:\PROGRAM FILES (X86)\EMBARCADERO\STUDIO\17.0\LIB\WIN32\RELEASE\C0D32.OBJ
Error: Unresolved external '__handle_wexitargv' referenced from C:\PROGRAM FILES (X86)\EMBARCADERO\STUDIO\17.0\LIB\WIN32\RELEASE\C0D32.OBJ
Error: Unresolved external '__fileinfo' referenced from C:\PROGRAM FILES (X86)\EMBARCADERO\STUDIO\17.0\LIB\WIN32\RELEASE\C0D32.OBJ
Error: Unresolved external '___CRTL_TLS_GetValue' referenced from C:\PROGRAM FILES (X86)\EMBARCADERO\STUDIO\17.0\LIB\WIN32\RELEASE\C0D32.OBJ
Error: Unresolved external '__turboFloat' referenced from root
Error: Unable to perform link
I'm kind of at a loss here. Any hints would be much appreciated.
After some pointers from the forums and a 11 years old post i added some extra .obj to the link line, namely cw32mt.lib and import32.lib, so that the final line looks something like this (YMMV):
ilink32.exe -q
-L"C:\path\to\lib\win32c\debug"
-L"C:\path\to\lib\win32\debug"
-LC:\MinGW\lib
-LC:\path\to\myProject
-Tpd /DEBUG
obj\Debug\subDir\file1.obj
obj\Debug\subDir\file2.obj,
bin\Debug\final.dll,,C:\path\to\myProject\some.lib
"C:\path\to\lib\win32c\debug\cw32mti.lib"
"C:\path\to\lib\win32c\debug\import32.lib",,
It is one single line, with some ,, and no spaces. Code::Blocks was handy too.
This is doing my nut in. I'm just trying to include pdcurses (i.e. ncurses for windows) into a test program. Linkage though is failing.
Using Visual Studio 2010.
I'm fully aware of setting up the correct link additional libraries path and to list the libraries themselves. No joy.
I've tried the various pre-builts on the pdcurses website. No such luck.
I of course resorted to building from source. Using nmake from the Visual Studio command prompt as prescribed. Built ok. Nada on link.
What am I missing. It's maybe just too late on Friday...
Output below:
1>------ Build started: Project: test, Configuration: Debug x64 ------
1>Build started 14/12/2012 16:24:32.
1>InitializeBuildStatus:
1> Touching "x64\Debug\test.unsuccessfulbuild".
1>ClCompile:
1> main.c
1>C:\dep\pdcurses\curses.h(160): warning C4005: 'MOUSE_MOVED' : macro redefinition
1> C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\include\wincon.h(101) : see previous definition of 'MOUSE_MOVED'
1>main.c(73): warning C4133: 'function' : incompatible types - from 'unsigned short [20]' to 'const char *'
1>ManifestResourceCompile:
1> All outputs are up-to-date.
1>main.obj : error LNK2019: unresolved external symbol endwin referenced in function main
1>main.obj : error LNK2019: unresolved external symbol wgetch referenced in function main
1>main.obj : error LNK2001: unresolved external symbol __imp_stdscr
1>main.obj : error LNK2019: unresolved external symbol refresh referenced in function main
1>main.obj : error LNK2019: unresolved external symbol printw referenced in function main
1>main.obj : error LNK2019: unresolved external symbol initscr referenced in function main
1>C:\proj\test.exe : fatal error LNK1120: 6 unresolved externals
1>
1>Build FAILED.
1>
1>Time Elapsed 00:00:01.47
Ok. I feel rather stupid. Here is the solution for posterity...
The distributed pdcurses binaries are 32bit. I was trying to build for 64bit.
Fundamentally, I forgot the first rule of linkage: don't mix and match architectures.
More specifically, when attempting to then build from source:
1) beware of starting the wrong Visual Studio command prompt. The default one from the Tools menu is the x86 one. If you just try and run cl.exe you'll find this out.
Instead, run the prompt from the start menu: Microsoft Visual Studio 2010->Visual Studio Tools->Visual Studio x64 Win64 Command Prompt (2010)
Invoke the build then by cd'ing to pdcurses directory/win32a and typing:
nmake -f vcwin32.mak DLL=pdcurses.dll
Also, 2) before you compile pdcurse change line 111 of the pdcurses Windows makefile (vcwin32.mak):
cvtres /MACHINE:X64 /NOLOGO /OUT:pdcurses.obj pdcurses.res
(NOTE: i.e. X64 architecture!)
Everything is now consistent. The pdcurses library will build. And it will link with my test app which (as the original output shows) I am building on x64.