Jump to content

  • Log In with Google      Sign In   
  • Create Account


#Actualmaxgpgpu

Posted 08 January 2013 - 01:54 PM

I've given you a -1 for "windoze" because it's rather silly and immature, but - without reviewing your full question - one item of info I cna give is that .lib files certainly can be .dll link stubs, and there are several examples of this throughout various MS SDKs (a .lib just contains code, and there's nothing to prevent that code from making LoadLibrary/GetProcAddress/FreeLibrary calls).

 

As an aside - any reason to not use Code::Blocks/MinGW on Windows?  It seems to me to make more sense to keep your builds consistent in this way than to deal with the hassle of moving between different build environments/processes.

 

Yes, I would like to develop with codeblocks on both platforms, and maybe someday I will go through the effort to do that.  In fact, I was going to make the switch now, but someone (from here on gamedev) wants to integrate my project with a project he is doing, and he is not willing to learn a new IDE.  So I'm putting up with VS2010 until I am finished helping him.

 

One problem with switching is that I have hundreds of #ifdefs LINUX and #ifdef OTHEROS in my code.  Right now they serve two purposes... differences between the two platforms/OS, and other differences.  In other words, I'm going to need to go look at every one of those #ifdefs and decide whether it needs to #ifdef on the basis of the OS-name, or on some other basis (like toolset: GNU vs VS).  I should have been more careful at the start, but I wasn't.

 

Switching to codeblocks/mingw should help me in another way too.  I have 4 separate assembly-language files for 32-bit linux, 64-bit linux, 32-bit VS, 64-bit VS.  In theory a single 32-bit assembly-language file in gas syntax should work on both, because the function protocols are the same, so presumably mingw gas should assemble and link the file correctly.  I'd still need a separate file for 64-bits, because the function protocols are drastically different.  It would still be a lot easier to translate them than currently, since they'd both be gas syntax.

 

Anyway, so the cairo.lib file might be a static DLL stub file that dynamically links to the cairo DLL file.  But my questions still remain.  Why doesn't it link?  What is that __imp__ prefix all about?  Why doesn't it find those symbols?  Maybe it is trying to link to the actual function names (as in a static linked library), but only finds those __imp__ prefix names.  Or maybe it is the other way around.

 

BTW, it is you who is incredibly immature.  Think about it.  Does bad spelling cause you cancer?  You can't believe how many times I've helped people, and spent a lot of time doing so, and not gotten thanks (or a +1 when here).  You are so petty or hyper-sensitive, I'm a bit stunned.


#4maxgpgpu

Posted 08 January 2013 - 01:31 PM

I've given you a -1 for "windoze" because it's rather silly and immature, but - without reviewing your full question - one item of info I cna give is that .lib files certainly can be .dll link stubs, and there are several examples of this throughout various MS SDKs (a .lib just contains code, and there's nothing to prevent that code from making LoadLibrary/GetProcAddress/FreeLibrary calls).

 

As an aside - any reason to not use Code::Blocks/MinGW on Windows?  It seems to me to make more sense to keep your builds consistent in this way than to deal with the hassle of moving between different build environments/processes.

 

Yes, I would like to develop with codeblocks on both platforms, and maybe someday I will go through the effort to do that.  In fact, I was going to make the switch now, but someone (from here on gamedev) wants to integrate my project with a project he is doing, and he is not willing to learn a new IDE.  So I'm putting up with VS2010 until I am finished helping him.

 

One problem with switching is that I have hundreds of #ifdefs LINUX and #ifdef OTHEROS in my code.  Right now they serve two purposes... differences between the two platforms/OS, and other differences.  In other words, I'm going to need to go look at every one of those #ifdefs and decide whether it needs to #ifdefe on the basis of the OS-name, or on some other basis (like toolset: GNU vs VS).  I should have been more careful at the start, but I wasn't.

 

Switching to codeblocks/mingw should help me in another way too.  I have 4 separate assembly-language files for 32-bit linux, 64-bit linux, 32-bit VS, 64-bit VS.  In theory a single 32-bit assembly-language file in gas syntax should work on both, because the function protocols are the same, so presumably mingw gas should assemble and link the file correctly.  I'd still need a separate file for 64-bits, because the function protocols are drastically different.  It would still be a lot easier to translate them than currently, since they'd both be gas syntax.

 

Anyway, so the cairo.lib file might be a static DLL stub file that dynamically links to the cairo DLL file.  But my questions still remain.  Why doesn't it link?  What is that __imp__ prefix all about?  Why doesn't it find those symbols?  Maybe it is trying to link to the actual function names (as in a static linked library), but only finds those __imp__ prefix names.  Or maybe it is the other way around.

 

BTW, it is you who is incredibly immature.  Think about it.  Does bad spelling cause you cancer?  You can't believe how many times I've helped people, and spent a lot of time doing so, and not gotten thanks (or a +1 when here).  You are so petty or hyper-sensitive, I'm a bit stunned.


#3maxgpgpu

Posted 08 January 2013 - 11:50 AM

I've given you a -1 for "windoze" because it's rather silly and immature, but - without reviewing your full question - one item of info I cna give is that .lib files certainly can be .dll link stubs, and there are several examples of this throughout various MS SDKs (a .lib just contains code, and there's nothing to prevent that code from making LoadLibrary/GetProcAddress/FreeLibrary calls).

 

As an aside - any reason to not use Code::Blocks/MinGW on Windows?  It seems to me to make more sense to keep your builds consistent in this way than to deal with the hassle of moving between different build environments/processes.

 

Yes, I would like to develop with codeblocks on both platforms, and maybe someday I will go through the effort to do that.  In fact, I was going to make the switch now, but someone (from here on gamedev) wants to integrate my project with a project he is doing, and he is not willing to learn a new IDE.  So I'm putting up with VS2010 until I am finished helping him.

 

One problem with switching is that I have hundreds of #ifdefs LINUX and #ifdef YOUKNOWWHAT in my code.  Right now they serve two purposes... differences between the two platforms/OS, and other differences.  In other words, I'm going to need to go look at every one of those #ifdefs and decide whether it needs to #ifdefe on the basis of the OS-name, or on some other basis (like toolset: GNU vs VS).  I should have been more careful at the start, but I wasn't.

 

Switching to codeblocks/mingw should help me in another way too.  I have 4 separate assembly-language files for 32-bit linux, 64-bit linux, 32-bit VS, 64-bit VS.  In theory a single 32-bit assembly-language file in gas syntax should work on both, because the function protocols are the same, so presumably mingw gas should assemble and link the file correctly.  I'd still need a separate file for 64-bits, because the function protocols are drastically different.  It would still be a lot easier to translate them than currently, since they'd both be gas syntax.

 

Anyway, so the cairo.lib file might be a static DLL stub file that dynamically links to the cairo DLL file.  But my questions still remain.  Why doesn't it link?  What is that __imp__ prefix all about?  Why doesn't it find those symbols?  Maybe it is trying to link to the actual function names (as in a static linked library), but only finds those __imp__ prefix names.  Or maybe it is the other way around.

 

BTW, it is you who is incredibly immature.  Think about it.  Does bad spelling cause you cancer?  You can't believe how many times I've helped people, and spent a lot of time doing so, and not gotten thanks (or a +1 when here).  You are so petty or hyper-sensitive, I'm a bit stunned.


#2maxgpgpu

Posted 08 January 2013 - 11:45 AM

I've given you a -1 for "windoze" because it's rather silly and immature, but - without reviewing your full question - one item of info I cna give is that .lib files certainly can be .dll link stubs, and there are several examples of this throughout various MS SDKs (a .lib just contains code, and there's nothing to prevent that code from making LoadLibrary/GetProcAddress/FreeLibrary calls).

 

As an aside - any reason to not use Code::Blocks/MinGW on Windows?  It seems to me to make more sense to keep your builds consistent in this way than to deal with the hassle of moving between different build environments/processes.

 

Yes, I would like to develop with codeblocks on both platforms, and maybe someday I will go through the effort to do that.  In fact, I was going to make the switch now, but someone (from here on gamedev) wants to integrate my project with a project he is doing, and he is not willing to learn a new IDE.  So I'm putting up with VS2010 until I am finished helping him.

 

Switching to codeblocks/mingw should help me in another way too.  I have 4 separate assembly-language files for 32-bit linux, 64-bit linux, 32-bit VS, 64-bit VS.  In theory a single 32-bit assembly-language file in gas syntax should work on both, because the function protocols are the same, so presumably mingw gas should assemble and link the file correctly.  I'd still need a separate file for 64-bits, because the function protocols are drastically different.  It would still be a lot easier to translate them than currently, since they'd both be gas syntax.

 

Anyway, so the cairo.lib file might be a static DLL stub file that dynamically links to the cairo DLL file.  But my questions still remain.  Why doesn't it link?  What is that __imp__ prefix all about?  Why doesn't it find those symbols?  Maybe it is trying to link to the actual function names (as in a static linked library), but only finds those __imp__ prefix names.  Or maybe it is the other way around.

 

BTW, it is you who is incredibly immature.  Think about it.  Does bad spelling cause you cancer?  You can't believe how many times I've helped people, and spent a lot of time doing so, and not gotten thanks (or a +1 when here).  You are so petty or hyper-sensitive, I'm a bit stunned.


#1maxgpgpu

Posted 08 January 2013 - 11:45 AM

I've given you a -1 for "windoze" because it's rather silly and immature, but - without reviewing your full question - one item of info I cna give is that .lib files certainly can be .dll link stubs, and there are several examples of this throughout various MS SDKs (a .lib just contains code, and there's nothing to prevent that code from making LoadLibrary/GetProcAddress/FreeLibrary calls).

 

As an aside - any reason to not use Code::Blocks/MinGW on Windows?  It seems to me to make more sense to keep your builds consistent in this way than to deal with the hassle of moving between different build environments/processes.

 

Yes, I would like to develop with codeblocks on both platforms, and maybe someday I will go through the effort to do that.  In fact, I was going to make the switch now, but someone (from here on gamedev) wants to integrate my project with a project he is doing, and he is not willing to learn a new IDE.  So I'm putting up with VS2010 until I am finished helping him.

 

Switching to codeblocks/mingw should help me in another way too.  I have 4 separate assembly-language files for 32-bit linux, 64-bit linux, 32-bit VS, 64-bit VS.  In theory a single 32-bit assembly-language file in gas syntax should work on both, because the function protocols are the same, so presumably mingw gas should assemble and link the file correctly.  I'd still need a separate file for 64-bits, because the function protocols are drastically different.  It would still be a lot easier to translate them than currently, since they'd both be gas syntax.

 

Anyway, so the cairo.lib file might be a static DLL stub file that dynamically links to the cairo DLL file.  But my questions still remain.  Why doesn't it link?  What is that __imp__ prefix all about?  Why doesn't it find those symbols?  Maybe it is trying to link to the actual function names (as in a static linked library), but only finds those __imp__ prefix names.  Or maybe it is the other way around.

 

BTW, it is you who is incredibly immature.  Think about it.  Does bad spelling cause you cancer?  You can't believe how many times I've helped people, and spent a lot of time doing so, and not gotten a +1 (or said anything about not getting one).  You are so petty or hyper-sensitive, I'm a bit stunned.


PARTNERS