From: Sisyphus <sis...@op...> - 2010-06-21 09:51:42
|
----- Original Message ----- From: "Arjen Markus" <arj...@de...> To: "Sisyphus" <sis...@op...> Cc: "Alessandro Piras" <la...@gm...>; <plp...@li...> Sent: Monday, June 21, 2010 5:20 PM Subject: Re: [Plplot-general] wingcc drivers fails to build on Windows 7 64bit/VC > Hi Rob, Alessandro, > > I have incorporated these proposed changes in the wingcc driver, > as suggested. For WIN32 platforms there is no GCLP_* macro defined, that > is only for WIN64 (at least that is what I see in one of the header > files on my system). So I kept the #ifdef. Yep, that's fine. However, I think you should find that both GCLP_HCURSOR and GWLP_USERDATA *are* defined for 32-bit compilers (and to the same values as their "P"-less counterparts). It's just that GCL_HCURSOR and GWL_USERDATA are not defined for Win64. For example, I think this should run fine on 32-bit compilers: ################################ #include <stdio.h> #include <windows.h> int main(void) { printf("%d %d\n%d %d\n", GCL_HCURSOR, GCLP_HCURSOR, GWL_USERDATA, GWLP_USERDATA); return 0; } ################################ So, either using the #ifdef (as I did) or changing to the "P" version (as Alessandro originally did) should both work ... for both 32 and 64 bits. I think the #ifdef approach is slightly better - if someone ever introduces other code into wingcc.c that contains either the GCL_HCURSOR or GWL_USERDATA symbols, then the #ifdef has already taken care of it. It's also safer ... in case there *are* some 32-bit compilers that are not defining GCLP_HCURSOR and GWLP_USERDATA. (As regards what the 32-bit compilers define, I've checked only with the mingw32 port of gcc-3.4.5 and MSVC++7.0.) > As I have no way to test this in the absence of a Windows 64 bits system > that I can easily use, I would like to ask you to check these changes. Just checked out revision 11081. Builds fine using MinGW64, except for the other issues I raised in my original post (and worked around): 1) I need to tell the build process that CC=x86_64-w64-mingw32-gcc, C++=x86_64-w64-mingw32-g++ and AR=x86_64-w64-mingw32-ar instead of the usual gcc, g++ and ar. I notice there's some output at the start of the cmake process that looks very much like './configure' output, so hopefully there's a way of passing those values along (as there is with ./configure). 2) libgdi32.a and libcomdlg32.a can't be found because of changes to the directory structure in the mingw64 compiler. I'll try to work out how those issues can be addressed - any pointers are welcome, as I'm not at all familiar with the cmake process, I'm hopeless at tracking down relevant documentation, I'm not very good with Makefiles, and I'm generally a bit dim anyway. Btw, by chance, I happened to notice that x17c.exe (strip chart demo) works correctly in the svn version. Whenever I've looked at it before, the graphs have just super-imposed over each other, resulting in quite a mess. Now we get one chart after another - which I'm assuming is what's intended. Nice ! Cheers, Rob |