Jump to content
  • Advertisement
Sign in to follow this  
InvalidPointer

C++/VS2008 linker PAIN AND SUFFERING

This topic is 3633 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hiya. Another question for all the programming gurus out there. I'm still working on a fully-featured game engine as a pet project. I decided it'd be best to try and go for a unified code base in the interest of ease of use. I'm trying to link with the OpenAL and DirectX10 libs but encounter the same problem-- when I use the #pragma comment(lib, "../blah.lib") functionality the linker complains that it can't locate the specified file with an error code of LNK1104. My actual code:
#if defined ( _WIN32 )
#pragma comment (lib, "../../DirectX/Libs/x86/d3d10.lib")
#elif defined ( _WIN64 )
#pragma comment (lib, "../../DirectX/Libs/x64/d3d10.lib")
#endif
and for OpenAL:
#if defined ( _WIN32 )
	#pragma comment(lib, "../OpenAL/libs/Win32/EFX-Util.lib")
	#pragma comment(lib, "../OpenAL/libs/Win32/OpenAL32.lib")
#elif defined ( _WIN64 )
	#pragma comment(lib, "../OpenAL/libs/Win64/OpenAL32.lib")
	#pragma comment(lib, "../OpenAL/libs/Win64/EFX-Util.lib")
#endif
I can confirm that the lib files do indeed exist where I'm specifying, and I haven't had any issues with header files, etc. in similar locations. Can anyone identify my problem and how to fix it?

Share this post


Link to post
Share on other sites
Advertisement
_WIN32: Defined for applications for Win32 and Win64. Always defined.
_WIN64: Defined for applications for Win64.

http://msdn.microsoft.com/en-us/library/b0084kay.aspx

Share this post


Link to post
Share on other sites
What is the exact error you get? If the linker says it can't find the file, then that sounds like the problem. Does it work if you put the .lib in the same directory as your solution file and not specify a path in the #pragma (E.g. "blah.lib")?

Share this post


Link to post
Share on other sites
Quote:
Original post by st
_WIN32: Defined for applications for Win32 and Win64. Always defined.
_WIN64: Defined for applications for Win64.

http://msdn.microsoft.com/en-us/library/b0084kay.aspx


I'll flip it, then. Thanks for the tip!

Quote:
Original post by Evil Steve
What is the exact error you get? If the linker says it can't find the file, then that sounds like the problem. Does it work if you put the .lib in the same directory as your solution file and not specify a path in the #pragma (E.g. "blah.lib")?

The error, verbatim, is
"fatal error LNK1104: cannot open file '../../DirectX/Libs/x86/d3d10.lib'"
I'll try that and post back, but I was hoping to avoid having to go this route, as again I'd like to keep everything unified.

Although now that you mention it, the path is relative to the header file I'm working from. Do I need to do it relative to the solution file?

EDIT: WIN. That was the problem. Why can't there be a standardized way of doing this? Ugh.

Share this post


Link to post
Share on other sites
Quote:
Original post by InvalidPointer
Although now that you mention it, the path is relative to the header file I'm working from. Do I need to do it relative to the solution file?
I believe so. I steer clear of relative paths for exactly this reason - you should set up your IDE to use the DirectX SDK dirs, then just specify the filename without the path in the #pragma.

Share this post


Link to post
Share on other sites
See edit. That was it. I chose to actually keep a copy of that stuff within my working directory for physical portability-- I can just pick up and go without needing to worry about SDK installation, etc. and all that hilarity. Thanks for the tips, both of you :)

Share this post


Link to post
Share on other sites
Quote:
Original post by InvalidPointer
See edit. That was it. I chose to actually keep a copy of that stuff within my working directory for physical portability-- I can just pick up and go without needing to worry about SDK installation, etc. and all that hilarity. Thanks for the tips, both of you :)
You really need the SDK properly installed to compile DirectX stuff. Pretty much every tutorial and downloadable code on the Internet assumes you have the SDK set up.
Using relative paths like this actually makes it harder to port, someone with the SDK correctly set up has to make sure that they copy your code to the correct directory relative to there. For instance, I keep visual studio installed on my C drive, but code is in a folder on my F drive.

Share this post


Link to post
Share on other sites
Quote:
Original post by Evil Steve
Quote:
Original post by InvalidPointer
See edit. That was it. I chose to actually keep a copy of that stuff within my working directory for physical portability-- I can just pick up and go without needing to worry about SDK installation, etc. and all that hilarity. Thanks for the tips, both of you :)
You really need the SDK properly installed to compile DirectX stuff. Pretty much every tutorial and downloadable code on the Internet assumes you have the SDK set up.
Using relative paths like this actually makes it harder to port, someone with the SDK correctly set up has to make sure that they copy your code to the correct directory relative to there. For instance, I keep visual studio installed on my C drive, but code is in a folder on my F drive.

I actually copied the include and lib directories into their own separate subfolders into my project. I have another thing set up for fxc, etc.

Share this post


Link to post
Share on other sites
Quote:
Original post by xZekex
Why don't you just link it normally in the project settings and not through #pragma stuff.


I lose the ability to cleanly differentiate between the 64- and 32-bit versions of the libraries.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!