aux_klib LNK4049: locally defined symbol KeGetCurrentIrql imported

NTDEV
1

When compiling under 2k3x64, I get this:

warnings in directory c:\projects\win-pvdrivers.hg\xenpci
c:\projects\win-pvdrivers.hg\xenpci\aux_klib.lib(aux_klib.obj) : warning
LNK4049: locally defined symbol KeGetCurrentIrql imported

Has anyone seen it before? It compiles fine under 2k3x32.

Thanks

James

2

I guess you can’t use x86-32 libraries for x86-64 builds.

Instead of copying aux_klib.lib to your project’s directory, better
include this line in your SOURCES file:
TARGETLIBS = $(TARGETLIBS) $(BASEDIR)\lib\wlh*\aux_klib.lib

  • Cay

On Fri, 16 Jan 2009 11:29:19 +0100, James Harper
wrote:
> When compiling under 2k3x64, I get this:
>
> warnings in directory c:\projects\win-pvdrivers.hg\xenpci
> c:\projects\win-pvdrivers.hg\xenpci\aux_klib.lib(aux_klib.obj) : warning
> LNK4049: locally defined symbol KeGetCurrentIrql imported
>
> Has anyone seen it before? It compiles fine under 2k3x32.
>
> Thanks
>
> James

3

>

I guess you can’t use x86-32 libraries for x86-64 builds.

Instead of copying aux_klib.lib to your project’s directory, better
include this line in your SOURCES file:
TARGETLIBS = $(TARGETLIBS) $(BASEDIR)\lib\wlh*\aux_klib.lib

Actually I fixed it by just copying the files from the wlh directory to
the wxp and wnet directories.

Previously, I was using the versions I downloaded from Microsoft.
Obviously that was the wrong thing to do - it worked under i386 but not
amd64.

Thanks

James

4

I’m not sure that’s a good idea, if I understand you correctly - you
replaced the libraries in the wxp and wnet directories with the ones in
the wlh directory? If nothing else, why both directories?

You aren’t by any chance using a non-standard build environment? Errors
like this are usually seen when the various macros that are set by the
build environment aren’t set correctly.

mm

James Harper wrote:

> I guess you can’t use x86-32 libraries for x86-64 builds.
>
> Instead of copying aux_klib.lib to your project’s directory, better
> include this line in your SOURCES file:
> TARGETLIBS = $(TARGETLIBS) $(BASEDIR)\lib\wlh*\aux_klib.lib
>

Actually I fixed it by just copying the files from the wlh directory to
the wxp and wnet directories.

Previously, I was using the versions I downloaded from Microsoft.
Obviously that was the wrong thing to do - it worked under i386 but not
amd64.

Thanks

James

5

I forgot the other reason why I think this is a build environment issue

  • KeGetCurrentIrql is inlined on x86_64, so whoever said something about
    x86_32 is probably correct.

At this point, assuming you copied files the way I think you did, or if
you changed anything else about your wdk installation, the first thing
you should do, in my opinion, is reinstall the wdk.

Good luck,

mm

Martin O’Brien wrote:

I’m not sure that’s a good idea, if I understand you correctly - you
replaced the libraries in the wxp and wnet directories with the ones in
the wlh directory? If nothing else, why both directories?

You aren’t by any chance using a non-standard build environment? Errors
like this are usually seen when the various macros that are set by the
build environment aren’t set correctly.

mm

James Harper wrote:
>> I guess you can’t use x86-32 libraries for x86-64 builds.
>>
>> Instead of copying aux_klib.lib to your project’s directory, better
>> include this line in your SOURCES file:
>> TARGETLIBS = $(TARGETLIBS) $(BASEDIR)\lib\wlh*\aux_klib.lib
>>
>
> Actually I fixed it by just copying the files from the wlh directory to
> the wxp and wnet directories.
>
> Previously, I was using the versions I downloaded from Microsoft.
> Obviously that was the wrong thing to do - it worked under i386 but not
> amd64.
>
> Thanks
>
> James
>

6

On Fri, 16 Jan 2009 15:10:06 +0100, Martin O’Brien
wrote:
> I’m not sure that’s a good idea, if I understand you correctly - you
> replaced the libraries in the wxp and wnet directories with the ones in
> the wlh directory? If nothing else, why both directories?

He copied, but didn’t replace any libraries, because for some reason, the
aux_klib.lib he also needs for prior build environments only exists in the
wlh lib path.
He’s not to blame, because it’s some weird decision (or perhaps error) the
WDK team is responsible for.

- Cay

7

May bad then.

Sorry about that.

mm

Cay Bremer wrote:

On Fri, 16 Jan 2009 15:10:06 +0100, Martin O’Brien
wrote:
>> I’m not sure that’s a good idea, if I understand you correctly - you
>> replaced the libraries in the wxp and wnet directories with the ones
>> in the wlh directory? If nothing else, why both directories?
>
> He copied, but didn’t replace any libraries, because for some reason,
> the aux_klib.lib he also needs for prior build environments only exists
> in the wlh lib path.
> He’s not to blame, because it’s some weird decision (or perhaps error)
> the WDK team is responsible for.
>
>
> - Cay
>

8

>

I’m not sure that’s a good idea, if I understand you correctly - you
replaced the libraries in the wxp and wnet directories with the ones
in
the wlh directory? If nothing else, why both directories?

Upon install, there is no aux_klib.lib in wnet or wxp (and probably w2k
either).

I downloaded the aux_klib.lib install from Microsoft for 32 and 64 bits
and put them in the wnet and wxp directories, and they built fine for 32
bit but not 64 bit.

I then replaced the files I’d installed in wnet and wxp with the one
from the wlh and it all worked fine. Google says that that’s what other
people are doing, or including the wlh directory on link (which I think
is a bad idea)

You aren’t by any chance using a non-standard build environment?
Errors
like this are usually seen when the various macros that are set by the
build environment aren’t set correctly.

I’m using 6001.18002, just installed.

James