Is it possible to use pragma lib in driver?

Morning, …and Evening everyone!

I’ve got a list of libraries that are used by a number of different drivers…
So it would be nice to use different versions of libraries for a specific product driver…
…kinda boost libs for kernel drivers

I wrote a script for creating TARGETNAME=COMPLIB_MJ_MN(d).lib, BUT!..
I found that it is very hard to do, here’s a list of reasons…

#pragma comment( lib, “XXX” ) - set an option for linker as /DEFAULTLIB:XXX
/NODEFAULTLIB - is allways defined by WDK nmake

So is it possible to use…
#pragma comment(lib, “XXX”)
in source files that uses XXX functionality?

(or may be… How to turn of /NODEFAULTLIB? )

Many thanks!

I don’t know, but let’s assume that it is by adding something to your
SOURCES file. If you’re have to add something, why not just add the
library name, which would also allow you to do it conditionally?

Personally, I think #pragma’s are among the most evil of features,
because they can be used to make fundamental changes, like optimization
options, and unless you actively look for them, it’s hard to keep in
mind that they could be the cause, because I at least don’t think of
them when I think about build settings. Also, because they do not
produce hard failure if they are not supported or what not, combined
with BUILD’s quirky ideas about what sort of errors and warnings that
actually want to know about, and those which you apparently wish it to
bury in incomprehensible files, this can also be difficult to diagnose.
If for some reason you change your mind down the road, you have to
check all your source files for statements like these, rather than just
changing your SOURCES file. Finally, if any of these problems become
manifest after you personally are no longer maintaining the code, the
next person who does might not appreciate this very much.

Good luck,

mm

xxxxx@mail.ru wrote:

Morning, …and Evening everyone!

I’ve got a list of libraries that are used by a number of different drivers…
So it would be nice to use different versions of libraries for a specific product driver…
…kinda boost libs for kernel drivers

I wrote a script for creating TARGETNAME=COMPLIB_MJ_MN(d).lib, BUT!..
I found that it is very hard to do, here’s a list of reasons…

#pragma comment( lib, “XXX” ) - set an option for linker as /DEFAULTLIB:XXX
/NODEFAULTLIB - is allways defined by WDK nmake

So is it possible to use…
#pragma comment(lib, “XXX”)
in source files that uses XXX functionality?

(or may be… How to turn of /NODEFAULTLIB? )

Many thanks!

Thanks for you reply…
…Sorry, I’ve dismissed a few details…
By default there is no TARGETNAME in “source” file and no “makefile” in the library project
So before build a driver the script is running which create “makefile” with correct
TARGETNAME like TARGETNAME=XXX_1_0b …everything is fine here…
BUT!
…I got a problem when linking the component that is using XXX_1_0b.lib
The name of correct version is generated from header(using “#pragma comment(lib, …)”) that is exported by the library project
But the problem appears… (reasons that I’ve found described in the first post)

…You…totally…lost…me…here…

mm

xxxxx@mail.ru wrote:

Thanks for you reply…
…Sorry, I’ve dismissed a few details…
By default there is no TARGETNAME in “source” file and no “makefile” in the library project
So before build a driver the script is running which create “makefile” with correct
TARGETNAME like TARGETNAME=XXX_1_0b …everything is fine here…
BUT!
…I got a problem when linking the component that is using XXX_1_0b.lib
The name of correct version is generated from header(using “#pragma comment(lib, …)”) that is exported by the library project
But the problem appears… (reasons that I’ve found described in the first post)

If you are generating your “sources” file with a script anyway,
why not add your (different) libs for each platform build?

TARGETLIBS= is your friend.

You can check what exactly was done by build.exe in the build logs.

xxxxx@mail.ru wrote:

Thanks for you reply…
…Sorry, I’ve dismissed a few details…
By default there is no TARGETNAME in “source” file and no “makefile” in the library project
So before build a driver the script is running which create “makefile” with correct
TARGETNAME like TARGETNAME=XXX_1_0b …everything is fine here…
BUT!
…I got a problem when linking the component that is using XXX_1_0b.lib
The name of correct version is generated from header(using “#pragma comment(lib, …)”) that is exported by the library project
But the problem appears… (reasons that I’ve found described in the first post)

In a proper design, version 1.6 of a library is still compatible with
version 1.2, so that a program written for 1.2 still works fine when
linked with 1.6. The whole concept of automatically generating library
names based on a version number is a very bad idea.


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

Dear Tim, don’t you think the same about boost libraries? BTW I don’t agree with the attitude about proper design… every component(library) is growing and sometimes architecture undergo changes
As the result we have a directory with all avaliable libraries of any verions

Once again “source” is not generated it is under source control, just without TARGETNAME
we gen “makefile” using the following script…
—8<--------------------------------------------------------------------------------------------------->8—
@setlocal ENABLEDELAYEDEXPANSION
@echo off

if “%1” == “” (
echo ERROR: Parameter wasn’t specified. Set include file path.
goto :eof
)

:
: Check if *.h exist
:
if not exist “%1” (
echo ERROR: %1 couldn’t be found.
goto :eof
)

if not exist sources (
echo ERROR: “Sources” file doesn’t exist.
goto :eof
)

findstr “TARGETNAME” sources>nul
if !errorlevel! == 0 (
echo ERROR: Found TARGETNAME in “Sources”, but name required to be generated automatically
goto :eof
)

:
: Get the project version
:
for /f "tokens=2 delims=COMPONENT_VER_MJ " %%i in (‘"findstr “COMPONENT_VER_MJ " %1”’) do set COMPONENT_VER_MJ=%%i&goto mj_found
:mj_found
for /f "tokens=2 delims=COMPONENT_VER_MN " %%i in (‘"findstr “COMPONENT_VER_MN " %1”’) do set COMPONENT_VER_MN=%%i&goto mn_found
:mn_found
for /f "tokens=2* delims=COMPONENT_NAME " %%i in (‘"findstr “COMPONENT_NAME " %1”’) do set COMPONENT_NAME=%%i&goto name_found
:name_found

set COMPONENT_NAME=!COMPONENT_NAME:"=!

if not “!COMPONENT_VER_MJ!”==“” (
if not “!COMPONENT_VER_MN!”==“” (
goto ver_ok
)
)
echo ERROR: COMPONENT_VER_MJ and COMPONENT_VER_MN MUST be declared in %1
echo INFO: Header file should contain following definitions to be correct.
echo INFO: —8<---- *.h ---->8—
echo INFO: #define COMPONENT_NAME “lower_case_name”
echo INFO: #define COMPONENT_VER_MJ V
echo INFO: #define COMPONENT_VER_MN V
echo INFO: —8<---- *.h ---->8—
goto :eof
:ver_ok

if exist makefile (
echo INFO: “makefile” will be overwritten…
)

echo TARGETNAME=!COMPONENT_NAME!!COMPONENT_VER_MJ!!COMPONENT_VER_MN!>makefile
endlocal
echo !IFNDEF FREEBUILD>>makefile
echo TARGETNAME=$(TARGETNAME)d>>makefile
echo !ENDIF>>makefile
echo !INCLUDE $(NTMAKEENV)\makefile.def>>makefile
—8<--------------------------------------------------------------------------------------------------->8—

Then a product if using any of libraries
should have a “source” file like this one
—8<--------------------------------------------------------------------------------------------------->8—…
TARGETLIBS=\dev\lib\kern\cache_1_2d.lib
or
TARGETLIBS=\dev\lib\kern\cache_1_2.lib
etc.
—8<--------------------------------------------------------------------------------------------------->8—
But just I want to specify
—8<--------------------------------------------------------------------------------------------------->8—

LINKER_FLAGS=$(LINKER_FLAGS) /LIBPATH:\dev\lib\kern

—8<--------------------------------------------------------------------------------------------------->8—
and to write the name in the header (using pragma comment lib…)
But I can’t …because…
“/NODEFAULTLIB option tells the linker to remove one or more default libraries from the list of libraries” (I got that info from the log, of course;)
I appreciate your ideas and experience, but I just want to get the way of disabling /NODEFAULTLIB
(and maybe env variable LIB which linker also uses for crt, etc…)

xxxxx@mail.ru wrote:

Dear Tim, don’t you think the same about boost libraries? BTW I don’t agree with the attitude about proper design… every component(library) is growing and sometimes architecture undergo changes
As the result we have a directory with all avaliable libraries of any verions

If you’re making a change in major version, like from mylib1.lib to
mylib2.lib, then I don’t have a problem with breaking compatibility.
But when you’re going from 1.1 to 1.2, I don’t think there is an excuse
for it.

Once again “source” is not generated it is under source control, just without TARGETNAME
we gen “makefile” using the following script…

Why don’t you just create a batch file with environment variable
definitions for the current versions of all of your libraries?

set CACHELIB=cache_1_2.lib
set CACHELIBD=cache_1_2d.lib

Then, in sources, you can say this:

TARGETLIBS=\dev\lib\kern$(CACHELIB)

But just I want to specify
—8<--------------------------------------------------------------------------------------------------->8—

LINKER_FLAGS=$(LINKER_FLAGS) /LIBPATH:\dev\lib\kern

—8<--------------------------------------------------------------------------------------------------->8—
and to write the name in the header (using pragma comment lib…)
But I can’t …because…
“/NODEFAULTLIB option tells the linker to remove one or more default libraries from the list of libraries” (I got that info from the log, of course;)
I appreciate your ideas and experience, but I just want to get the way of disabling /NODEFAULTLIB
(and maybe env variable LIB which linker also uses for crt, etc…)

Nope. The master makefile that “sources” invokes is in
DDK\6000\bin\makefile.new. You can see that /NODEFAULTLIB is added
unconditionally. I suspect that’s done to avoid accidentally bringing
in user-mode libraries.


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

Yep! Setting env var is kinda solution and if documented properly - could be used. Thanks!