#pragma comment( lib, <filespec> ): may <filespec> be a relative path?
Angel Tsankov
![Carl Daniel [VC++ MVP]'s profile photo](https://lh3.googleusercontent.com/a/default-user=s40-c)
Carl Daniel [VC++ MVP]
> May I specify a relative or an absolute path in the pragma comment
> lib directive? If so, how?
No, just a file name. The linker will search the library paths (specified in
the environment or command line) to find the library.
-cd
David Lowndes
The MSDN documentation implies that you can. I've never tried it
myself though:
"
lib
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.
"
Dave
Angel Tsankov
Yes, it does not say that it is impossible and that's why I asked how it is done.
David Lowndes
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!
Dave
Angel Tsankov
I tried with a relative path like this:
#pragma comment( lib, "dir/file.lib" )
and got the same error.
David Lowndes
>
>#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
8\\VC\\PlatformSDK\\Lib\\user32.lib" )
Dave
Angel Tsankov
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:
d:\libraries\library_files
d:\libraries\library_files\
d:/libraries/library_files
d:/libraries/library_files/
The full path to the .lib file is
d:\libraries\library_files\dir\file.lib
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
lib directive.
David Lowndes
>Relative paths, however, do not work. I tried the following:
>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
>lib directive.
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
for.
Dave
James Park
news:440af48b$0$15789$1472...@news.sunsite.dk...
I have no problems specifying paths relative to the source file.
David Lowndes
>> a relative (i.e. an incomplete path) in a pragma comment lib directive.
>
>I have no problems specifying paths relative to the source file.
Perhaps you can give us an example that works for you James?
Dave
James Park
news:26vm021e85mn0d08i...@4ax.com...
No problemo:
#include <windows.h>
#include <tchar.h>
#pragma comment( lib, "..\\..\\..\\..\\..\\..\\..\\Program Files\\Microsoft
Visual Studio 8\\VC\\PlatformSDK\\Lib\\user32.lib" )
int _tmain(int argc, _TCHAR* argv[])
{
UNREFERENCED_PARAMETER(argc);
UNREFERENCED_PARAMETER(argv);
FindWindow(NULL, NULL);
}
Carl Daniel [VC++ MVP]
> "David Lowndes" <Dav...@example.invalid> wrote in message
> news:26vm021e85mn0d08i...@4ax.com...
>>>> 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 lib
>>>> directive.
>>>
>>> I have no problems specifying paths relative to the source file.
>>
>> Perhaps you can give us an example that works for you James?
>
> No problemo:
>
> #include <windows.h>
> #include <tchar.h>
>
> #pragma comment( lib, "..\\..\\..\\..\\..\\..\\..\\Program
> Files\\Microsoft Visual Studio 8\\VC\\PlatformSDK\\Lib\\user32.lib" )
... 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
haven't).
-cd
James Park
wrote in message news:OTd%23SIOQ...@TK2MSFTNGP12.phx.gbl...
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.
Carl Daniel [VC++ MVP]
> "Carl Daniel [VC++ MVP]"
>>> #pragma comment( lib, "..\\..\\..\\..\\..\\..\\..\\Program
>>> Files\\Microsoft Visual Studio 8\\VC\\PlatformSDK\\Lib\\user32.lib"
>>> )
>>
>> ... 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 haven't).
>
> 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...
-cd
Benjamin B.
> May I specify a relative or an absolute path in the pragma comment lib
> directive? If so, how?
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.
Cheers
Benjamin
David Lowndes
>also tried copying user32.lib to the directory one level above and using
>"..\\user32.lib" and that built fine too.
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.
Dave
James Park
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.
James Park
> >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.
>
> Strange, that doesn't work for me.
>
> Try moving it to a sub-directory from one of the lib paths.
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.
David Lowndes
>>
>> Try moving it to a sub-directory from one of the lib paths.
>
>Both "sub\\user32.dll" and ".\\sub\\user32.dll" work fine for me.
.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
in?
Dave
James Park
>>> Strange, that doesn't work for me.
>>>
>>> Try moving it to a sub-directory from one of the lib paths.
>>
>>Both "sub\\user32.dll" and ".\\sub\\user32.dll" work fine for me.
>
> .dll or .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
> in?
The user32.lib for this example has this absolute path:
C:\Documents and Settings\James\My Documents\Visual Studio
2005\Projects\CppTest\CppTest\sub\User32.lib
And the command prompt would look something like:
C:\Documents and Settings\James\My Documents\Visual Studio
2005\Projects\CppTest\CppTest>link.exe ...
David Lowndes
>
>C:\Documents and Settings\James\My Documents\Visual Studio
>2005\Projects\CppTest\CppTest\sub\User32.lib
>
>And the command prompt would look something like:
>
>C:\Documents and Settings\James\My Documents\Visual Studio
>2005\Projects\CppTest\CppTest>link.exe ...
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.
Dave
Tim Roberts
>
>Angel Tsankov schrieb:
>> May I specify a relative or an absolute path in the pragma comment lib
>> directive? If so, how?
>
>What's that "feature" good for anyway?
>Has linking suddenly become part of application logic?
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.
Benjamin B.
> "Benjamin B." <no....@today.com> wrote:
>> Angel Tsankov schrieb:
>>> May I specify a relative or an absolute path in the pragma comment lib
>>> directive? If so, how?
>> What's that "feature" good for anyway?
>> Has linking suddenly become part of application logic?
>
> 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?
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.
Cheers
Benjamin
Tim Roberts
>
>Tim Roberts wrote:
>> "Benjamin B." <no....@today.com> wrote:
>>> Angel Tsankov schrieb:
>>>> May I specify a relative or an absolute path in the pragma comment lib
>>>> directive? If so, how?
>>> What's that "feature" good for anyway?
>>> Has linking suddenly become part of application logic?
>>
>> 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?
>
>You're saying it yourself: It's embedding it. It's (kind of) hiding it.
>It's not visible at first glance.
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.
