D3DX11Effects.lib x64
Author
I can't build an x64 version of D3DX11Effects.lib in 2008? 2010Beta won't import the project, Win7 did something funny to the 2010Beta loader.... Why am I building this lib file anyway? Anywhere I can download this?
[edit]
The Visual C++ 2008 Express Edition can be used to compile .NET as well as Win32 applications immediately after installation. However, natively compiling 64-bit applications through the IDE is not supported without some involved configurations. If the freely available Windows SDK is installed, 64-bit applications can be built on the command line using the x64 cross-compiler (Cl.exe) supplied with the SDK.[9] True integration of 64bit compilers to the Visual C++ 2008 Express Edition is possible, but remains cumbersome.
[/edit]
Nein!
I hang my head in shame.....
Author
Attempted to relocate to VS2010Beta......
Issues:
> What about the locking issues in the 2008 STL implementation? I have an application where the single greatest performance bottleneck is the thread locking in the STL.
In VC9 (aka VS 2008), the STL proper doesn't take locks in release mode. To clarify:
"In VC9" - we recently noticed that in VC10 Beta 1, the STL proper is taking locks in release mode. This was an unintended side effect of fusing _SECURE_SCL and _HAS_ITERATOR_DEBUGGING into _ITERATOR_DEBUG_LEVEL, and we've got a bug tracking this.
"the STL proper" - as in, things like vectors and algorithms, not iostreams. iostreams takes locks in order to allow cout to be used by multiple threads (since streaming through cout is a modifying operation).
"in release mode" - as in, /MT or /MD (with _SECURE_SCL, now _ITERATOR_DEBUG_LEVEL, set to either 0 or 1). In debug mode (/MTd or /MDd) with _HAS_ITERATOR_DEBUGGING enabled (now, _ITERATOR_DEBUG_LEVEL set to 2), locks are used to protect the bookkeeping data structures for the powerful correctness checks. If you're profiling debug mode, don't do that.
Also, this excludes whatever happens during memory allocation.
-msdn blog
Hey this could be good??? Does this mean the lib file worked lolz
1>Link:1> D3DX11Effects.lib(EffectAPI.obj) : MSIL .netmodule or module compiled with /GL found; restarting link with /LTCG; add /LTCG to the link command line to improve linker performance1>D3DX11Effects.lib(EffectAPI.obj) : error LNK2038: mismatch detected for '_ITERATOR_DEBUG_LEVEL': value '0' doesn't match value '2' in DirectDraw.obj1>D3DX11Effects.lib(EffectNonRuntime.obj) : error LNK2038: mismatch detected for '_ITERATOR_DEBUG_LEVEL': value '0' doesn't match value '2' in DirectDraw.obj1>D3DX11Effects.lib(EffectLoad.obj) : error LNK2038: mismatch detected for '_ITERATOR_DEBUG_LEVEL': value '0' doesn't match value '2' in DirectDraw.obj1>D3DX11Effects.lib(d3dxGlobal.obj) : error LNK2038: mismatch detected for '_ITERATOR_DEBUG_LEVEL': value '0' doesn't match value '2' in DirectDraw.obj1>D3DX11Effects.lib(EffectReflection.obj) : error LNK2038: mismatch detected for '_ITERATOR_DEBUG_LEVEL': value '0' doesn't match value '2' in DirectDraw.obj1>D3DX11Effects.lib(EffectRuntime.obj) : error LNK2038: mismatch detected for '_ITERATOR_DEBUG_LEVEL': value '0' doesn't match value '2' in DirectDraw.obj1>MSVCRTD.lib(cinitexe.obj) : warning LNK4098: defaultlib 'msvcrt.lib' conflicts with use of other libs; use /NODEFAULTLIB:library1>D3DX11Effects.lib(EffectLoad.obj) : error LNK2001: unresolved external symbol D3DGetInputSignatureBlob1>D3DX11Effects.lib(EffectLoad.obj) : error LNK2001: unresolved external symbol D3DReflect1>C:\Projects\DUALITY\X64\Debug\DUALITY.exe : fatal error LNK1120: 2 unresolved externalsIssues:
> What about the locking issues in the 2008 STL implementation? I have an application where the single greatest performance bottleneck is the thread locking in the STL.
In VC9 (aka VS 2008), the STL proper doesn't take locks in release mode. To clarify:
"In VC9" - we recently noticed that in VC10 Beta 1, the STL proper is taking locks in release mode. This was an unintended side effect of fusing _SECURE_SCL and _HAS_ITERATOR_DEBUGGING into _ITERATOR_DEBUG_LEVEL, and we've got a bug tracking this.
"the STL proper" - as in, things like vectors and algorithms, not iostreams. iostreams takes locks in order to allow cout to be used by multiple threads (since streaming through cout is a modifying operation).
"in release mode" - as in, /MT or /MD (with _SECURE_SCL, now _ITERATOR_DEBUG_LEVEL, set to either 0 or 1). In debug mode (/MTd or /MDd) with _HAS_ITERATOR_DEBUGGING enabled (now, _ITERATOR_DEBUG_LEVEL set to 2), locks are used to protect the bookkeeping data structures for the powerful correctness checks. If you're profiling debug mode, don't do that.
Also, this excludes whatever happens during memory allocation.
-msdn blog
Hey this could be good??? Does this mean the lib file worked lolz
Author
/MD => /MDd in D3DX11Effects project......
-.- I are so close to a working core(well raw core!)
p.s. D2D is still not DX11 functional in the new SDK :( I don't want to key mutex, blah blah... I'm no good at sharing....
[Edited by - jpetrie on February 23, 2010 10:22:34 AM]
1> Generating Code...1>D3DX11Effects.lib(EffectLoad.obj) : error LNK2019: unresolved external symbol D3DGetInputSignatureBlob referenced in function "protected: long __cdecl D3DX11Effects::CEffectLoader::BuildShaderBlock(struct D3DX11Effects::SShaderBlock *)" (?BuildShaderBlock@CEffectLoader@D3DX11Effects@@IEAAJPEAUSShaderBlock@2@@Z)1>D3DX11Effects.lib(EffectLoad.obj) : error LNK2019: unresolved external symbol D3DReflect referenced in function "protected: long __cdecl D3DX11Effects::CEffectLoader::BuildShaderBlock(struct D3DX11Effects::SShaderBlock *)" (?BuildShaderBlock@CEffectLoader@D3DX11Effects@@IEAAJPEAUSShaderBlock@2@@Z)1>C:\Projects\DUALITY\X64\Debug\DUALITY.exe : fatal error LNK1120: 2 unresolved externals1>-.- I are so close to a working core(well raw core!)
p.s. D2D is still not DX11 functional in the new SDK :( I don't want to key mutex, blah blah... I'm no good at sharing....
[Edited by - jpetrie on February 23, 2010 10:22:34 AM]
Author
Thought it was included in the effects project!
#pragma comment (lib, "d3dcompiler.lib")
Anybody know why all this was necessary?
#pragma comment (lib, "d3dcompiler.lib")
Anybody know why all this was necessary?
Quote:
Anybody know why all this was necessary?
It wasn't for us when we built it for SlimDX, so you must have something odd going on.
Author
Quote:Original post by jpetrieQuote:
Anybody know why all this was necessary?
It wasn't for us when we built it for SlimDX, so you must have something odd going on.
Aside from D2D, I hope not.
You had D3DX11Effects.lib already compiled in your Lib folder? There it is, I'm using x64! The x64 lib file is non existent and probably for good reason. I do have reasons for using x64..... I hope the fact that mine is 20Megs as opposed to 14 is not problematic in the future. I wonder when /MDd debugger effects is going to kick me in the ass?
"...you must have something odd going on..." <==== what are you saying?(I am currently listening to a song that is repeating "OMG Ice cream") o-o
Quote:
Aside from D2D, I hope not.
Irrelevant to the process of building Effects11. I mean things like broken paths, etc.
Quote:
You had D3DX11Effects.lib already compiled in your Lib folder? There it is, I'm using x64! The x64 lib file is non existent and probably for good reason. I do have reasons for using x64..... I hope the fact that mine is 20Megs as opposed to 14 is not problematic in the future.
No, Effects11 is not distributed in binary form in the SDK. You have to build it yourself. I'm saying we had no real trouble making it build for both 32-bit and 64-bit platforms when we needed to do so, so something about the process you're using or the state of your toolchain is incorrect.
Quote:
I wonder when /MDd debugger effects is going to kick me in the ass?
This smacks of illogical and poorly-conceived 'shotgun debugging' -- changing a bunch of things quickly, out of frustration, without really understanding what you are changing or why. This is never a good solution to a problem.
In particular, the "problems" that are likely to arise from using /MDd are not problems with /MDd itself. /MDd links to debug runtimes, by design. You'll have trouble shipping products like that -- the problem is that you shouldn't be linking to debug runtimes, not that /MDd is broken in any fashion.
Author
Quote:Original post by jpetrieQuote:
Aside from D2D, I hope not.
Irrelevant to the process of building Effects11. I mean things like broken paths, etc.
this is why I had to switch to /MDd????
Quote:Original post by jpetrieQuote:
You had D3DX11Effects.lib already compiled in your Lib folder? There it is, I'm using x64! The x64 lib file is non existent and probably for good reason. I do have reasons for using x64..... I hope the fact that mine is 20Megs as opposed to 14 is not problematic in the future.
No, Effects11 is not distributed in binary form in the SDK. You have to build it yourself. I'm saying we had no real trouble making it build for both 32-bit and 64-bit platforms when we needed to do so, so something about the process you're using or the state of your toolchain is incorrect.
Oh yeah I put that there :)... As stated earlier I'm using VS2008 Express and/or VS2010Beta. Express is not released through MS with x64 compiling. VS2010Beta was not importing the 2008 project, it repeatedly crashed. I will be purchasing a full version of 2010 Professional when it is released. This last bit is kind of pointless because the chances of me successfully releasing commercial software is pretty slim. I'm also not a certified SE so putting in bids on contracts is pretty silly...... and well see Interview@Google in the lounge....
Quote:Quote:
I wonder when /MDd debugger effects is going to kick me in the ass?
This smacks of illogical and poorly-conceived 'shotgun debugging' -- changing a bunch of things quickly, out of frustration, without really understanding what you are changing or why. This is never a good solution to a problem.
In particular, the "problems" that are likely to arise from using /MDd are not problems with /MDd itself. /MDd links to debug runtimes, by design. You'll have trouble shipping products like that -- the problem is that you shouldn't be linking to debug runtimes, not that /MDd is broken in any fashion.
I know...... D2D is causing problems I'm working around that for the moment!
"You'll have trouble shipping products like that" <=== is this a vote of confidence?
Quote:
this is why I had to switch to /MDd????
That makes no sense. Do you even know what the /MDd flag does? You should not have to compile Effects11 with the /MDd flag in order to be able to link it with other code that is also using D2D. You're doing something wrong.
Quote:
As stated earlier I'm using VS2008 Express and/or VS2010Beta. Express is not released through MS with x64 compiling.
I know. You can, however, use the cross-compiler as you noted. That should not necessitate having to link against the debug runtimes (/MDd).
Quote:
I know...... D2D is causing problems I'm working around that for the moment!
The problems with D2D are different than the problems you have building Effects11. I would resolve those first before worrying about D2D.
Quote:
"You'll have trouble shipping products like that" <=== is this a vote of confidence?
No, it's a fact. /MDd links to the debug runtimes. This means that in order to run your code, the end-user must also have those debug runtimes. Most users don't -- only developers generally do. Furthermore, you cannot distribute those runtimes, so you must tell your users to download Visual Studio (essentially) in order to run your application.
Even if you do not intend to ship this product to anybody, this is absolutely horrid practice. You should try to figure out what the root cause of your problem is, and what options other than linking to the debug runtimes are available to you.
What happens when you attempt to compile the (virgin, unmodified) Effects11 library using the 64-bit cross compiler? What errors do you get? Et cetera? Make sure this is an unmodified version of the source, too, not something you have tampered with, no matter how trivial you believe your changes to be.
Author
I never had errors in the effects project, I had errors in my project which was using the effects project. The only errors I had where related to D2D, in my project(using the same compiler line as the 'virgin project' as you put it.) I haven't used the cross compiler. If you think it might fix the LNK2038 D2D was generating then I'll give it a try, it would be nice to avoid using debug runtime workaround. I had no intention on keeping the workaround a part of my project as I was somewhat aware of what I was doing, just not entirely, as would someone who has more under-stranding.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement