I’m building a driver using the Windows 2000 Free Build environment. Some
of the code in my driver does a % operation on two unsigned long long’s,
which causes the compiler to generate a reference to a helper function
__aulldvrm. But when I try to link the driver, the linker can’t resolve
this symbol because it’s not defined in any of the DDK .lib files I’m
linking against! The DDK .lib’s that build.exe chooses to link with are:
ntoskrnl.lib
hal.lib
wmilib.lib
sehupd.lib
After digging around in the .lib files, I’ve found that I can work around
this by including $DDK_LIB_PATH\ntstrsafe.lib in my TARGETLIBS, but I would
really rather not having to do that if possible. Is there a cleaner way to
get around the problem - either with some compiler option to avoid the call
to __aulldvrm, or some other .lib reference I can use? Thanks for any help
on this!
Ernie Coskrey
It’s been a while since I’ve done this, but you may be able to force the
compiler to use intrinsic functions for all long longs…something like
#pragma intrinsic _int64
You might dig around in the #pragma for int64 intrinsics… Like I said,
it’s been a while and the details are a bit fuzzy.
Hope that helps…
Greg
The only solution I’ve found to this is to include the WNET
lib\wnet*\int64.lib in the TARGETLIBS – this issue is caused by the fact
that you are using a different compiler now that emits different code for 64
bit ops so the old W2K libraries don’t have the correctly named helper
routines.
/simgr
-----Original Message-----
From: Ernie Coskrey [mailto:xxxxx@steeleye.com]
Sent: Monday, August 25, 2003 9:22 AM
To: Windows System Software Developers Interest List
Subject: [ntdev] Working around __aulldvrm ref in W2K .obj
I’m building a driver using the Windows 2000 Free Build environment. Some
of the code in my driver does a % operation on two unsigned long long’s,
which causes the compiler to generate a reference to a helper function
__aulldvrm. But when I try to link the driver, the linker can’t resolve
this symbol because it’s not defined in any of the DDK .lib files I’m
linking against! The DDK .lib’s that build.exe chooses to link with are:
ntoskrnl.lib
hal.lib
wmilib.lib
sehupd.lib
After digging around in the .lib files, I’ve found that I can work around
this by including $DDK_LIB_PATH\ntstrsafe.lib in my TARGETLIBS, but I would
really rather not having to do that if possible. Is there a cleaner way to
get around the problem - either with some compiler option to avoid the call
to __aulldvrm, or some other .lib reference I can use? Thanks for any help
on this!
Ernie Coskrey
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@stratus.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
Get a copy of Visual C and look for a file called ulldvrm.obj in the CRT
source directory. Link to it.
Ernie Coskrey wrote:
I’m building a driver using the Windows 2000 Free Build environment. Some
of the code in my driver does a % operation on two unsigned long long’s,
which causes the compiler to generate a reference to a helper function
__aulldvrm. But when I try to link the driver, the linker can’t resolve
this symbol because it’s not defined in any of the DDK .lib files I’m
linking against! The DDK .lib’s that build.exe chooses to link with are:
ntoskrnl.lib
hal.lib
wmilib.lib
sehupd.lib
After digging around in the .lib files, I’ve found that I can work around
this by including $DDK_LIB_PATH\ntstrsafe.lib in my TARGETLIBS, but I would
really rather not having to do that if possible. Is there a cleaner way to
get around the problem - either with some compiler option to avoid the call
to __aulldvrm, or some other .lib reference I can use? Thanks for any help
on this!
Ernie Coskrey
–
Nick Ryan (MVP for DDK)