Ok I’ve been staring at this for a while now and I don’t see what I’m missing.
I want to link to fltLib.lib from a UM C++ application compiled with VC++.
In fltUser.h the functions are explicitly declared as WINAPI, and they are surrounded in extern “C” if it is compiled with a c++ compiler.
So I add the lib to the project (I use code::blocks). But the linker complains that the function I call is unresolved.
So, in an effort to find the problem I compile a static library of my own with the DDK, and try to link to it with VC++. Same problem:
// The library:
// umFsLib.h
#ifdef __cplusplus
extern “C” {
#endif
int __stdcall test();
#ifdef __cplusplus
}
#endif
// umFsLib.c
int __stdcall test(){
return 4;
}
// The UM C++ compiled with VC++:
#include
int _cdecl main (
in int argc,
in_ecount(argc) char *argv )
{
test();
return 0;
}
// LINK error: unresolved external symbol xxxxx@0 referenced in function _main|
////////
So I am explicitly adding the calling convention as the DDK uses a different default as VC++, I surround the header in extern “C”…
If I dumpbin /exports my library and the DDK’s fltLib.lib then the latter does have exports and my lib does not, but as far as I know this should not matter as it is a static lib.
My SOURCES file for the umFsLib:
TARGETNAME=umFsLib
TARGETTYPE=LIBRARY
TARGETPATH=…..\lib
USE_MSVCRT=1
LINKLIBS=$(SDK_LIB_PATH)\shell32.lib
INCLUDES=$(INCLUDES); <br> $(IFSKIT_INC_PATH); <br> $(DDK_INC_PATH); <br> …..\inc\umFsLib
TARGETLIBS=$(TARGETLIBS) <br> $(IFSKIT_LIB_PATH)\fltLib.lib
SOURCES=umFsLib.c
I guess I am overlooking something small, but I don’t see it :S and to be honoust I am quite embarassed to even have to ask this question.
xxxxx@gmail.com wrote:
Ok I’ve been staring at this for a while now and I don’t see what I’m missing.
I want to link to fltLib.lib from a UM C++ application compiled with VC++.
In fltUser.h the functions are explicitly declared as WINAPI, and they are surrounded in extern “C” if it is compiled with a c++ compiler.
So I add the lib to the project (I use code::blocks). But the linker complains that the function I call is unresolved.
So, in an effort to find the problem I compile a static library of my own with the DDK, and try to link to it with VC++. Same problem:
My congratulations on including your full source code with your
question. I was able to build the library and link it to your main
program without a problem.
How did you add the library to the project? Are you sure it is being
passed to the linker? The symptom certainly looks like it was not.
With the VC++ IDE, you have to add the library to the “additional
dependency” list; adding it to the “project” is not enough.
If I dumpbin /exports my library and the DDK’s fltLib.lib then the latter does have exports and my lib does not, but as far as I know this should not matter as it is a static lib.
Right, /exports is the wrong switch for a static library. Try “dumbin
/linkermember”.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
It looks like your library is somehow not getting passed to VC.
You might want to add the ‘-VERBOSE:LIB’ option to the linker command line/VC options. It will dump the chain of libraries it searches when resolving symbols.
Good luck,
mm
I’m afraid it does include the library:
Searching libraries
Searching …..\lib\amd64\umFsLib.lib:
As mentioned I use Code::Blocks for my development, but I will try to compile the project tomorrow at my university with Visual Studio.
I’ll update on the progress.
xxxxx@gmail.com wrote:
I’m afraid it does include the library:
Searching libraries
Searching …..\lib\amd64\umFsLib.lib:
As mentioned I use Code::Blocks for my development, but I will try to compile the project tomorrow at my university with Visual Studio.
I’ll update on the progress.
Are you building in a 64-bit build environment? Did you intend to do so?
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Just to check something, you said you are using “Code::Blocks” which
Wikipedia says is a platform portable library that may be compiled under a
variety of compilers. Are you using a Microsoft compiler? You said you used
VC++ but you also said you would try it under VisualStudio, which makes me
wonder what VC++ actually is. Just for clarification, what is “VC++” by your
definition.
In general, compiling a library with one brand of compiler and linking it
with code compiled with a different brand often does not work. The C++
language may be the same, but the language run-time and things like object
code name mangling are often vendor specific.
Microsoft would probably say the only compiler guaranteed compatible with
libraries that are part of a specific WDK version, is the exactly compiler
that comes with that WDK version.
Jan
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:bounce-410868-
xxxxx@lists.osr.com] On Behalf Of Tim Roberts
Sent: Monday, May 10, 2010 3:31 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] fltLib.lib and VC++
xxxxx@gmail.com wrote:
> I’m afraid it does include the library:
> Searching libraries
> Searching …..\lib\amd64\umFsLib.lib:
>
> As mentioned I use Code::Blocks for my development, but I will try to
compile the project tomorrow at my university with Visual Studio.
>
> I’ll update on the progress.
>
Are you building in a 64-bit build environment? Did you intend to do
so?
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
> Are you building in a 64-bit build environment? Did you intend to do so?
I am such an idiot… yes it is my intend to build in a 64-bit environment, but I should build my VC++ usermode application in 64-bit as well then… man I can’t believe I didnt see that :S, thank you.
@Jan Bottorf:
Yes, Code::Blocks allows you to chose a compiler. VC++ by my definition is the Microsoft C++ compiler. What I meant with “trying it in Visual Studio” was merely to see if I linked to the lib correctly with C::B, a weak try it would be but I was kind of desperate :P.
So seeing as this is working I can now directly link to the fltLib.lib as well.
I’m still hitting myself for having to ask this question, thanks Tim !