No, just a file name. The linker will search the library paths (specified in
the environment or command line) to find the library.
The MSDN documentation implies that you can. I've never tried it
Places a library-search record in the object file. This comment type
must be accompanied by a commentstring parameter containing the name
(and possibly the path) of the library that you want the linker to
search. The library name follows the default library-search records in
the object file; the linker searches for this library just as if you
had named it on the command line provided that the library is not
specified with /nodefaultlib. You can place multiple library-search
records in the same source file; each record appears in the object
file in the same order in which it is encountered in the source file.
If the order of the default library and an added library is important,
compiling with the /Zl switch will prevent the default library name
from being placed in the object module. A second comment pragma then
can be used to insert the name of the default library after the added
library. The libraries listed with these pragmas will appear in the
object module in the same order they are found in the source code.
Yes, it does not say that it is impossible and that's why I asked how it is done.
What have you tried, and what's been the result?
I've just tried this:
#pragma comment( lib, "c:\\rubbish\\user32.lib" )
and got this:
fatal error LNK1104: cannot open file 'c:\rubbish\user32.lib'
So it clearly does what it says to some degree!
I tried with a relative path like this:
#pragma comment( lib, "dir/file.lib" )
and got the same error.
Right... so, where is file.lib in relation to other things?
What are you expecting it to do...?
Try a fixed path to exactly where your lib is and see if that works,
this does for me.
#pragma comment( lib, "C:\\Program Files\\Microsoft Visual Studio
Yes, a fixed (absolute) path works for me, too.
Relative paths, however, do not work. I tried the following:
#pragma comment( lib, "/dir/file.lib" )
#pragma comment( lib, "\\dir\\file.lib" )
#pragma comment( lib, ".\\dir\\file.lib" )
in combination Library files in the IDE containg any of these paths:
The full path to the .lib file is
Having tried all this, I tend to assume that it is not possible to specify a relative (i.e. an incomplete path) in a pragma comment
As the documentation makes no specific reference to relative paths,
I'd have to conclude from the results you show that it's not catered
I have no problems specifying paths relative to the source file.
Perhaps you can give us an example that works for you James?
#pragma comment( lib, "..\\..\\..\\..\\..\\..\\..\\Program Files\\Microsoft
Visual Studio 8\\VC\\PlatformSDK\\Lib\\user32.lib" )
int _tmain(int argc, _TCHAR* argv)
... which would have worked even if the linker ignored the path completely.
Have you tried a .lib that's in a directory that's not on the lib path? (I
I've tried using a bad path (removed one "..\\") and that didn't build. I've
also tried copying user32.lib to the directory one level above and using
"..\\user32.lib" and that built fine too.
Sounds like it works then :)
In your test, was the .obj file in the same directory as the source file?
It would seem odd that a path relative to the source file would be
meaningful to the linker...
What's that "feature" good for anyway?
Has linking suddenly become part of application logic?
How about a separation of concerns?
Me, I'm using linker arguments in the project settings.
Strange, that doesn't work for me.
Try moving it to a sub-directory from one of the lib paths.
I can't seem to make relative paths work.
My .obj file is .\Debug away from my source file, but you're right that it's
not relative to the source. I just tested quickly from the command-line and
it seems to be relative to the path from which the linker is run.
Both "sub\\user32.dll" and ".\\sub\\user32.dll" work fine for me.
> I can't seem to make relative paths work.
Try making them relative to the path from which the linker is run.
.dll or .lib?
>> I can't seem to make relative paths work.
>Try making them relative to the path from which the linker is run.
I'm not sure what you mean by that - it seems a bit ambiguous, so to
clarify, can you show the absolute path that you now have user32.lib
Sorry, I meant lib. I thought it was short enough that I could remember it
w/o needing to go back and copy/paste but obviously not :).
>>> I can't seem to make relative paths work.
>>Try making them relative to the path from which the linker is run.
> I'm not sure what you mean by that - it seems a bit ambiguous, so to
> clarify, can you show the absolute path that you now have user32.lib
The user32.lib for this example has this absolute path:
C:\Documents and Settings\James\My Documents\Visual Studio
And the command prompt would look something like:
C:\Documents and Settings\James\My Documents\Visual Studio
OK, I can confirm that it does work where the comment library path is
relative to the project build directory. I was sort of expecting it to
work relative to the normal LIB directories, but that doesn't seem to
be the case.
Why not? If I'm calling APIs from my_dll.dll in a particular source
module, why shouldn't that C module embed the library requirement? Why
should I have to embed that knowledge separately from the module?
>How about a separation of concerns?
>Me, I'm using linker arguments in the project settings.
And when you copy that source file into another project, you will have to
build it and get a linker error before you remember "oh, that's right, I
need to add my_dll.lib to the project settings."
- Tim Roberts, ti...@probo.com
Providenza & Boekelheide, Inc.
You're saying it yourself: It's embedding it. It's (kind of) hiding it.
It's not visible at first glance.
>> How about a separation of concerns?
>> Me, I'm using linker arguments in the project settings.
> And when you copy that source file into another project, you will have to
> build it and get a linker error before you remember "oh, that's right, I
> need to add my_dll.lib to the project settings."
Portability is an issue here, I think.
How can one assume that library names are the same on different platforms?
Or, to be more general: What's being passed to the linker is an
argument, no matter if that's a library or an option. How can one assume
that a different linker accepts the same arguments?
Besides, my personal opinion is that concerns should be and have to be
separated. And linking is a task that has absolutely nothing to do with
my program logic.
One may even sometimes want to use a different library, or the same
library in a different version, implementing the same interface.
And, yes, one may get a linker error sometimes. That's exactly what
linker errors are for. To make you wonder if you have that library, if
you have it in the version which you want. Costs 10 seconds and assures
that you're doing the right thing.
Boy, I have to say that I see this in EXACTLY the opposite way. Embedding
the library eight levels deep in some property page inside "project
settings", or whatever the name is today, is my definition of "hiding".
When the library name in the source file that needs it, or the include file
that declares it, makes it clearly visible.