From: Alessandro P. <la...@gm...> - 2010-06-20 12:05:32
|
The wingcc driver is using obsolete constants: GCL_HCURSOR GWL_USERDATA that should be replaced by GCLP_HCURSOR GWLP_USERDATA as in http://msdn.microsoft.com/en-us/library/aa383663.aspx I tried to fix it replacing the constants, but It does not work well: x01c.exe starts, it plots the graphics, and after half a second the window "the program stopped working appears". ... if ( pls ) { dev = (wingcc_Dev *) pls->dev; // This is the offending line (256) } ... No idea what's going on, just reporting it :-) __ Alessandro |
From: Sisyphus <sis...@op...> - 2010-06-20 14:25:42
|
----- Original Message ----- From: "Alessandro Piras" <la...@gm...> To: <plp...@li...> Sent: Sunday, June 20, 2010 10:04 PM Subject: [Plplot-general] wingcc drivers fails to build on Windows 7 64bit/VC > > The wingcc driver is using obsolete constants: > GCL_HCURSOR > GWL_USERDATA > > that should be replaced by > GCLP_HCURSOR > GWLP_USERDATA I struck the same issue when building with MinGW. I resolved it by inserting #ifdef _WIN64 #define GWL_USERDATA GWLP_USERDATA #define GCL_HCURSOR GCLP_HCURSOR #endif into drivers/wingcc.c (near the beginning of that file, immediately after the #include'ing of <windows .h>). That took care of the problem for me. I don't know if it will fix it for you .... sounds like it might not ... :-) Cheers, Rob |
From: Sisyphus <sis...@op...> - 2010-06-20 23:19:37
|
----- Original Message ----- From: "Alessandro Piras" <la...@gm...> To: "Sisyphus" <sis...@op...> > Hi Rob, > > for what I understood from the Microsoft docs (correct me if I'm wrong) > GWLP_* and GCLP_* constants should work on both 32bit and 64bit windows. Haven't checked the documentation, but looking at winuser.h, that appears to be the case. > Renaming those constants fixes the build problem, but the examples will > crash when selecting the wingcc driver (which is the only one > interactive driver I've been able to use kind of reliably with > windows/sbcl/cl-plplot). > > Does the driver work correctly when built with mingw64? Yes, though I've only built with -DBUILD_SHARED_LIBS=OFF . I had to copy libgdi32.a and libcomdlg32.a from the /mingw/lib folder to the /lib folder, otherwise they are not found and the process tries to link to the system dll's (and fails). One other complication for me was that I use the cross-compiler (where the gcc executable is not actually named 'gcc.exe'). See my post of 12 June titled '[Win32] x64 build of plplot' for a more detailed account. You'll avoid that naming issue if you grab the "sezero" binary which, I think, is to be found under the "Personal Builds" section. Cheers, Rob |
From: Arjen M. <arj...@de...> - 2010-06-21 07:21:06
|
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. 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. Regards, Arjen On 2010-06-21 01:18, Sisyphus wrote: > ----- Original Message ----- > From: "Alessandro Piras" <la...@gm...> > To: "Sisyphus" <sis...@op...> > >> Hi Rob, >> >> for what I understood from the Microsoft docs (correct me if I'm wrong) >> GWLP_* and GCLP_* constants should work on both 32bit and 64bit windows. > > Haven't checked the documentation, but looking at winuser.h, that appears to > be the case. > >> Renaming those constants fixes the build problem, but the examples will >> crash when selecting the wingcc driver (which is the only one >> interactive driver I've been able to use kind of reliably with >> windows/sbcl/cl-plplot). >> >> Does the driver work correctly when built with mingw64? > > Yes, though I've only built with -DBUILD_SHARED_LIBS=OFF . > > I had to copy libgdi32.a and libcomdlg32.a from the /mingw/lib folder to the > /lib folder, otherwise they are not found and the process tries to link to > the system dll's (and fails). > > One other complication for me was that I use the cross-compiler (where the > gcc executable is not actually named 'gcc.exe'). See my post of 12 June > titled '[Win32] x64 build of plplot' for a more detailed account. You'll > avoid that naming issue if you grab the "sezero" binary which, I think, is > to be found under the "Personal Builds" section. > > Cheers, > Rob > > > > ------------------------------------------------------------------------------ > ThinkGeek and WIRED's GeekDad team up for the Ultimate > GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the > lucky parental unit. See the prize list and enter to win: > http://p.sf.net/sfu/thinkgeek-promo > _______________________________________________ > Plplot-general mailing list > Plp...@li... > https://lists.sourceforge.net/lists/listinfo/plplot-general > |
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 |
From: Werner S. <sm...@ia...> - 2010-06-21 12:45:47
|
Hi Sisyphus, On 6/21/10 11:48 AM, Sisyphus wrote: > > ----- 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. This is right done in CMakeLists.txt in the main directory: # We need the path to the MinGW/Borland compiler in order to find # the import libraries for system libraries. IF(MINGW) get_filename_component(MINGWBINPATH ${CMAKE_C_COMPILER} PATH) set(MINGWLIBPATH ${MINGWBINPATH}/../lib CACHE FILEPATH DOCSTRING "Path to MinGW import libraries") ENDIF(MINGW) IF(BORLAND) get_filename_component(BORLANDBINPATH ${CMAKE_C_COMPILER} PATH) set(BORLANDLIBPATH ${BORLANDBINPATH}/../Lib/PSDK CACHE FILEPATH DOCSTRING "Path to Borland import libraries") ENDIF(BORLAND) I think you just need to add ${MINGWBINPATH}/../mingw/lib to MINGWLIBPATH since this is a list anyway (I hope). Then cmake should find the gdi lib "automatically". If this works for you, I'll add it to the CMakeLists.txt. Regards, Werner > > 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 > > > ------------------------------------------------------------------------------ > ThinkGeek and WIRED's GeekDad team up for the Ultimate > GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the > lucky parental unit. See the prize list and enter to win: > http://p.sf.net/sfu/thinkgeek-promo > _______________________________________________ > Plplot-general mailing list > Plp...@li... > https://lists.sourceforge.net/lists/listinfo/plplot-general -- Dr. Werner Smekal Institut fuer Angewandte Physik Technische Universitaet Wien Wiedner Hauptstr 8-10/134 A-1040 Wien Austria DVR-Nr: 0005886 email: sm...@ia... (GPG: EDCAF4A79) web: http://www.iap.tuwien.ac.at/~smekal phone: +43-(0)1-58801-13463 (office) +43-(0)1-58801-13469 (laboratory) fax: +43-(0)1-58801-13499 |
From: Sisyphus <sis...@op...> - 2010-06-21 14:45:19
|
----- Original Message ----- From: "Werner Smekal" <sm...@ia...> > This is right done in CMakeLists.txt in the main directory: > > # We need the path to the MinGW/Borland compiler in order to find > # the import libraries for system libraries. > IF(MINGW) > get_filename_component(MINGWBINPATH ${CMAKE_C_COMPILER} PATH) > set(MINGWLIBPATH ${MINGWBINPATH}/../lib > CACHE FILEPATH > DOCSTRING "Path to MinGW import libraries") > ENDIF(MINGW) > IF(BORLAND) > get_filename_component(BORLANDBINPATH ${CMAKE_C_COMPILER} PATH) > set(BORLANDLIBPATH ${BORLANDBINPATH}/../Lib/PSDK > CACHE FILEPATH > DOCSTRING "Path to Borland import libraries") > ENDIF(BORLAND) Yes, I've just been playing with that. Changing set(MINGWLIBPATH ${MINGWBINPATH}/../lib to set(MINGWLIBPATH ${MINGWBINPATH}/../mingw/lib certainly works. But it's not portable, as ${MINGWBINPATH}/../mingw/lib is not always the correct location. > I think you just need to add ${MINGWBINPATH}/../mingw/lib to > MINGWLIBPATH since this is a list anyway (I hope). Oh, it's a *list* ? Lemme see .... so it is ! Wow ... that makes it *so* much easier. If I change that line to set(MINGWLIBPATH ${MINGWBINPATH}/../lib ${MINGWBINPATH}/../mingw/lib it works for both my 32-bit and 64-bit compiler. While you're at it, you might also add ${MINGWBINPATH}/../x86_64-w64-mingw32/lib and ${MINGWBINPATH}/../i686-w64-mingw32/lib to that list. By way of explanation: The current setting accommodates only the mingw.org directory structure for their 32-bit compiler. (That's the 32-bit compiler that I use.) Adding ${MINGWBINPATH}/../mingw/lib will accommodate the 64-bit cross-compiler provided by mingw64.sf.net. (That's the 64-bit compiler that I use.) Adding ${MINGWBINPATH}/../x86_64-w64-mingw32/lib will accommodate the 64-bit "sezero"[1] compiler (not a cross-compiler) provided by mingw64.sf.net. (That's the 64-bit compiler used by sane people, and Strawberry Perl [2]) Adding ${MINGWBINPATH}/../i686-w64-mingw32/lib will accommodate the 32-bit "sezero"[1] compiler provided by mingw64.sf.net. (That's the 32-bit compiler that's used by Strawberry Perl.) [1] "sezero" is just the nick of the guy who builds those compiler versions. [2] No, I'm not trying to insinuate that Strawberry Perl is insane. I've made some progress on modifying the name of the C compiler, too. I've found that instead of copying 'x86_64-w64-mingw32-gcc.exe' to 'gcc.exe' I can just use the -DCMAKE_C_COMPILER option to specify the correct name. For some strange reason that I haven't yet fathomed, specifying the name of the C++ compiler (which is 'x86_64-w64-mingw32-g++.exe' ) using -DCMAKE_CXX_COMPILER fails to work. I get: -- The CXX compiler identification is unknown -- Check for working CXX compiler: g++.exe ... groan ... but then, I don't really give a rat's arse about C++ :-) (I will, however, out of curiosity, try to find out what's going on there.) Haven't yet worked out how I'm supposed to tell the process that 'ar.exe' is really named 'x86_64-w64-mingw32-ar.exe' . Anyone know ? Cheers, Rob |
From: Alan W. I. <ir...@be...> - 2010-06-21 21:17:19
|
On 2010-06-22 00:43+1000 Sisyphus wrote: > For some strange reason that I haven't yet fathomed, specifying the name of > the C++ compiler (which is 'x86_64-w64-mingw32-g++.exe' ) > using -DCMAKE_CXX_COMPILER fails to work. I get: > > -- The CXX compiler identification is unknown > -- Check for working CXX compiler: g++.exe > > ... groan ... but then, I don't really give a rat's arse about C++ :-) > (I will, however, out of curiosity, try to find out what's going on there.) Assuming x86_64-w64-mingw32-g++.exe is on your PATH, my guess is the "++" is causing problems in the name of the executable. You may need to quote it ('++') or even escape it inside quotes ('\+\+') before cmake can find that executable for itself. There is probably special code within CMake to find g++.exe (with no prefix) without further help, but that is probably not true of x86_64-w64-mingw32-g++.exe. > Haven't yet worked out how I'm supposed to tell the process that 'ar.exe' is > really named 'x86_64-w64-mingw32-ar.exe' . Anyone know ? What do you get for CMAKE_AR:FILEPATH in your CMakeCache.txt file? If that is not the correct value, I think you should be able to override it with -DCMAKE_AR:FILEPATH=\whatever\path\to\ar\x86_64-w64-mingw32-ar.exe Often, looking at results in CMakeCache.txt and deploying a corresponding -D option to change values is the only step you will need to solve problems like this where you are (apparently) dealing with a new platform that CMake is not aware of yet so that essential platform constants are not set correctly. Of course, the proper way to set platform-dependent constants is with a new or modified file in (e.g., $prefix/share/cmake-2.8/Modules/Platform/. However, platform files are sometimes a difficult topic, so I would report what constants you need to set with -D to the CMake developers at the cm...@cm... mailing list with an exact description of your platform so they can figure out what platform file changes need to be done to make the experience for the next user of your platform much smoother. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Sisyphus <sis...@op...> - 2010-06-22 03:32:09
|
----- Original Message ----- From: "Alan W. Irwin" <ir...@be...> >> -- The CXX compiler identification is unknown >> -- Check for working CXX compiler: g++.exe > Assuming x86_64-w64-mingw32-g++.exe is on your PATH, my guess is the "++" > is > causing problems in the name of the executable. You may need to quote it > ('++') or even escape it inside quotes ('\+\+') before cmake can find that > executable for itself. There is probably special code within CMake to > find g++.exe (with no prefix) without further help, but that is probably > not true of x86_64-w64-mingw32-g++.exe. Haven't yet found a rendition that works. I've even created a copy of the g++ executable called 'cpp.exe' and tried to use it. I've tried altering CMAKE_CXX_COMPILER and CMAKE_CXX_COMPILER:FILEPATH, but it's always the same error (as above). I think the failure to access cpp.exe indicates that there's more to the problem than just the '+' symbols. It's as though there's a decision made somewhere in the sources that the g++ executable has to be named 'g++.exe' and nothing else is acceptable. >> Haven't yet worked out how I'm supposed to tell the process that 'ar.exe' >> is >> really named 'x86_64-w64-mingw32-ar.exe' . Anyone know ? > > What do you get for CMAKE_AR:FILEPATH in your CMakeCache.txt file? If > that > is not the correct value, I think you should be able to override it with > -DCMAKE_AR:FILEPATH=\whatever\path\to\ar\x86_64-w64-mingw32-ar.exe > Yes, that works nicely. Thanks. > Of course, the proper way to set platform-dependent constants is with a > new > or modified file in (e.g., $prefix/share/cmake-2.8/Modules/Platform/. > However, platform files are sometimes a difficult topic, so I would report > what constants you need to set with -D to the CMake developers at the > cm...@cm... mailing list with an exact description of your platform so > they can figure out what platform file changes need to be done to > make the experience for the next user of your platform much smoother. Most people who build with MinGW64 use the "sezero" version of the compiler where the various executables (gcc, g++, ar, etc.) are given their usual names. The only problems they will come up against are the wingcc.c code (already fixed in svn) and the absence of a correct library path in the MINGWLIBPATH list in CMakeLists.txt. Once that has been taken care of, they're right to go without any need for changes to platform files. As regards the extra requirements that need to be met when the cross-compiler is being used, I'll consider raising it with the developers as you suggest - though I'm not sure that setting up new platform files just to accommodate the mingw64 cross-compiler is really worth the effort (given that very few seem to use that particular compiler, and those that do probably accept that they need to take some extra steps themselves). A ,mention on how to build with the cross-compiler on the wiki might be handy, however. Anyway, I'd like to first work out why I can't get the build process to use x86_64-w64-mingw32-g++.exe. Thanks muchly for the pointers. Cheers, Rob |
From: Arjen M. <arj...@de...> - 2010-06-22 07:03:39
|
Hi Rob, as you do not care for C++, you can always switch it off using the option -DENABLE_cxx:BOOL=OFF. To solve the problem with the +'s in "g++", you might try to create a link to that executable with an inconspicuous name. I am not sure if that works under CMake (not sure these Windows links are transparant enough), but it might be worth a try. Or use a batchfile instead. Regards, Arjen On 2010-06-22 05:30, Sisyphus wrote: > ----- Original Message ----- > From: "Alan W. Irwin" <ir...@be...> > >>> -- The CXX compiler identification is unknown >>> -- Check for working CXX compiler: g++.exe > >> Assuming x86_64-w64-mingw32-g++.exe is on your PATH, my guess is the "++" >> is >> causing problems in the name of the executable. You may need to quote it >> ('++') or even escape it inside quotes ('\+\+') before cmake can find that >> executable for itself. There is probably special code within CMake to >> find g++.exe (with no prefix) without further help, but that is probably >> not true of x86_64-w64-mingw32-g++.exe. > > Haven't yet found a rendition that works. I've even created a copy of the > g++ executable called 'cpp.exe' and tried to use it. I've tried altering > CMAKE_CXX_COMPILER and CMAKE_CXX_COMPILER:FILEPATH, but it's always the same > error (as above). I think the failure to access cpp.exe indicates that > there's more to the problem than just the '+' symbols. > It's as though there's a decision made somewhere in the sources that the g++ > executable has to be named 'g++.exe' and nothing else is acceptable. > >>> Haven't yet worked out how I'm supposed to tell the process that 'ar.exe' >>> is >>> really named 'x86_64-w64-mingw32-ar.exe' . Anyone know ? >> What do you get for CMAKE_AR:FILEPATH in your CMakeCache.txt file? If >> that >> is not the correct value, I think you should be able to override it with >> -DCMAKE_AR:FILEPATH=\whatever\path\to\ar\x86_64-w64-mingw32-ar.exe >> > > Yes, that works nicely. Thanks. > >> Of course, the proper way to set platform-dependent constants is with a >> new >> or modified file in (e.g., $prefix/share/cmake-2.8/Modules/Platform/. >> However, platform files are sometimes a difficult topic, so I would report >> what constants you need to set with -D to the CMake developers at the >> cm...@cm... mailing list with an exact description of your platform so >> they can figure out what platform file changes need to be done to >> make the experience for the next user of your platform much smoother. > > Most people who build with MinGW64 use the "sezero" version of the compiler > where the various executables (gcc, g++, ar, etc.) are given their usual > names. The only problems they will come up against are the wingcc.c code > (already fixed in svn) and the absence of a correct library path in the > MINGWLIBPATH list in CMakeLists.txt. Once that has been taken care of, > they're right to go without any need for changes to platform files. > > As regards the extra requirements that need to be met when the > cross-compiler is being used, I'll consider raising it with the developers > as you suggest - though I'm not sure that setting up new platform files just > to accommodate the mingw64 cross-compiler is really worth the effort (given > that very few seem to use that particular compiler, and those that do > probably accept that they need to take some extra steps themselves). A > ,mention on how to build with the cross-compiler on the wiki might be handy, > however. > > Anyway, I'd like to first work out why I can't get the build process to use > x86_64-w64-mingw32-g++.exe. > > Thanks muchly for the pointers. > > Cheers, > Rob > > > ------------------------------------------------------------------------------ > ThinkGeek and WIRED's GeekDad team up for the Ultimate > GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the > lucky parental unit. See the prize list and enter to win: > http://p.sf.net/sfu/thinkgeek-promo > _______________________________________________ > Plplot-general mailing list > Plp...@li... > https://lists.sourceforge.net/lists/listinfo/plplot-general > |
From: Sisyphus <sis...@op...> - 2010-06-22 08:11:02
|
----- Original Message ----- From: "Arjen Markus" <arj...@de...> To: "Sisyphus" <sis...@op...> Cc: "plplot" <plp...@li...> Sent: Tuesday, June 22, 2010 5:03 PM Subject: Re: [Plplot-general] wingcc drivers fails to build onWindows 7 64bit/VC > Hi Rob, > > as you do not care for C++, you can always switch it off using the > option -DENABLE_cxx:BOOL=OFF. No need - the errors turn it off automatically ;-) > To solve the problem with the +'s in "g++", you might try to create a > link to that executable with an inconspicuous name. I am not sure if > that works under CMake (not sure these Windows links are transparant > enough), but it might be worth a try. Or use a batchfile instead. I'm fairly sure there's no problem with the + symbols. I strike the same problem trying to access x86_64-w64-mingw32-gfortran.exe. So far I've managed to access only the gcc and ar executables without renaming them. Curious though it is, it's not such a big issue - I can always create copies named 'g++.exe' and 'gfortran.exe' if I want to build c++ and fortran libraries. (It works fine for both - I've checked.) I'm thinking the problem has something to do with the way cmake goes about validating these compilers. I'm currently looking at CMakeDetermineCompilerId.cmake as that's where the "compiler identification is unknown" messages that I'm also getting seem to originate ... but I don't really understand what I'm looking at. I'll give it a rest for a while and see if anything comes to light .... Apologies to Alessandro, too - his thread seems to have been hijacked :-) Cheers, Rob |
From: Arjen M. <arj...@de...> - 2010-06-21 10:02:44
|
Hi Rob, On 2010-06-21 11:48, Sisyphus wrote: > > 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. > Hm, I founded my comment on this piece of code (from c:\program files\microsoft sdks\windows\v6.0A\include\winuser.h): #ifdef _WIN64 #undef GCL_MENUNAME #undef GCL_HBRBACKGROUND #undef GCL_HCURSOR #undef GCL_HICON #undef GCL_HMODULE #undef GCL_WNDPROC #undef GCL_HICONSM #endif /* _WIN64 */ #define GCLP_MENUNAME (-8) #define GCLP_HBRBACKGROUND (-10) #define GCLP_HCURSOR (-12) #define GCLP_HICON (-14) #define GCLP_HMODULE (-16) #define GCLP_WNDPROC (-24) #define GCLP_HICONSM (-34) #endif /* !NOWINOFFSETS */ As you can see, it undefines the GCL_* macros before redefining them when _WIN64 exists. This may be peculiar to this version and to the MicroSoft Visual Studio version it comes with. The header file that comes with the GCC compiler does not undefine the GCL_* macros. That is the difference. > >> 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): > Excellent. > 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. > Hm, you have solved (or tracked down the solution to) those issues, so the dimness seems to be wearing off. I guess Windows 64 bits is a relatively new platform as far as PLplot is concerned. We are bound to run into more such issues. > 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 ! > Yes, that was actually a small correction by me and great improvement to the demo (the wingcc was lying about it cleaning up the window - it said it would but did not). Regards, Arjen |
From: Sisyphus <sis...@op...> - 2010-06-21 10:57:01
|
----- Original Message ----- From: "Arjen Markus" <arj...@de...> To: "Sisyphus" <sis...@op...> Cc: "Alessandro Piras" <la...@gm...>; <plp...@li...> Sent: Monday, June 21, 2010 8:02 PM Subject: Re: [Plplot-general] wingcc drivers fails to build on Windows 7 64bit/VC > Hi Rob, > > On 2010-06-21 11:48, Sisyphus wrote: > >> >> 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. >> > > Hm, I founded my comment on this piece of code (from c:\program > files\microsoft sdks\windows\v6.0A\include\winuser.h): > > > #ifdef _WIN64 > > #undef GCL_MENUNAME > #undef GCL_HBRBACKGROUND > #undef GCL_HCURSOR > #undef GCL_HICON > #undef GCL_HMODULE > #undef GCL_WNDPROC > #undef GCL_HICONSM > > #endif /* _WIN64 */ > > #define GCLP_MENUNAME (-8) > #define GCLP_HBRBACKGROUND (-10) > #define GCLP_HCURSOR (-12) > #define GCLP_HICON (-14) > #define GCLP_HMODULE (-16) > #define GCLP_WNDPROC (-24) > #define GCLP_HICONSM (-34) > > #endif /* !NOWINOFFSETS */ > > As you can see, it undefines the GCL_* macros before redefining them > when _WIN64 exists. This may be peculiar to this version and to the > MicroSoft Visual Studio version it comes with. If you look closely, you'll see that GCL_CURSOR is indeed undefined for Win64 (as you say), but GCLP_HCURSOR is defined for both Win32 and Win64. (I initially made the same error when I first looked at the code - but the definition of GCLP_HCURSOR is made *outside* of the "#ifdef _WIN64" block.) > The header file that comes with the GCC compiler does not undefine > the GCL_* macros. That is the difference. The ports of gcc available from mingw64.sf.net do undefine those macros for _WIN64. But you're right, the gcc ports from mingw.org don't. Instead they just define both the "P" and "no P" macros. That may be a mistake ... not sure. I'm not aware of it ever causing any problems - and I'm sure that it would be addressed if it did ever cause problems. >> 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 ! >> > > Yes, that was actually a small correction by me and great improvement > to the demo (the wingcc was lying about it cleaning up the window - it > said it would but did not). Yes, definitely an improvement ! I hate it when computers misbehave. Reminds me of a computer called "HAL", in a movie called "2001, A Space Odyssey" ......... ;-) Cheers, Rob |
From: Arjen M. <arj...@de...> - 2010-06-21 11:02:19
|
Hi Rob, oops, you are right On 2010-06-21 12:55, Sisyphus wrote: > > If you look closely, you'll see that GCL_CURSOR is indeed undefined for > Win64 (as you say), but GCLP_HCURSOR is defined for both Win32 and > Win64. (I initially made the same error when I first looked at the code > - but the definition of GCLP_HCURSOR is made *outside* of the "#ifdef > _WIN64" block.) > >> The header file that comes with the GCC compiler does not undefine >> the GCL_* macros. That is the difference. > > The ports of gcc available from mingw64.sf.net do undefine those macros > for _WIN64. But you're right, the gcc ports from mingw.org don't. > Instead they just define both the "P" and "no P" macros. That may be a > mistake ... not sure. I'm not aware of it ever causing any problems - > and I'm sure that it would be addressed if it did ever cause problems. > > > Yes, definitely an improvement ! > I hate it when computers misbehave. Reminds me of a computer called > "HAL", in a movie called "2001, A Space Odyssey" ......... ;-) > (Ever read "When Harley was one"? Can't remember the author, but it impressed me at the time.) What I really detest is programs that try to be too helpful - Windows 7 on my laptop at home is for some reason very helpful ... let the mouse hover above a program icon too long and it will think that is what you want to start :(. But that is not PLplot-related of course. Regards, Arjen |
From: Alessandro P. <la...@gm...> - 2010-06-21 19:41:15
|
Hi Arjen, i just pulled from git, it builds fine but still crashes when I run the examples. I built it using visual studio x64 tools, on windows 7 64. If I can help you to identify the problem, I'll be glad to. Cheers, Alessandro Arjen Markus <arj...@de...> writes: > 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. > > 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. > > Regards, > > Arjen > > On 2010-06-21 01:18, Sisyphus wrote: >> ----- Original Message ----- >> From: "Alessandro Piras" <la...@gm...> >> To: "Sisyphus" <sis...@op...> >> >>> Hi Rob, >>> >>> for what I understood from the Microsoft docs (correct me if I'm wrong) >>> GWLP_* and GCLP_* constants should work on both 32bit and 64bit windows. >> >> Haven't checked the documentation, but looking at winuser.h, that appears to >> be the case. >> >>> Renaming those constants fixes the build problem, but the examples will >>> crash when selecting the wingcc driver (which is the only one >>> interactive driver I've been able to use kind of reliably with >>> windows/sbcl/cl-plplot). >>> >>> Does the driver work correctly when built with mingw64? >> >> Yes, though I've only built with -DBUILD_SHARED_LIBS=OFF . >> >> I had to copy libgdi32.a and libcomdlg32.a from the /mingw/lib folder to the >> /lib folder, otherwise they are not found and the process tries to link to >> the system dll's (and fails). >> >> One other complication for me was that I use the cross-compiler (where the >> gcc executable is not actually named 'gcc.exe'). See my post of 12 June >> titled '[Win32] x64 build of plplot' for a more detailed account. You'll >> avoid that naming issue if you grab the "sezero" binary which, I think, is >> to be found under the "Personal Builds" section. >> >> Cheers, >> Rob >> >> >> >> ------------------------------------------------------------------------------ >> ThinkGeek and WIRED's GeekDad team up for the Ultimate >> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the >> lucky parental unit. See the prize list and enter to win: >> http://p.sf.net/sfu/thinkgeek-promo >> _______________________________________________ >> Plplot-general mailing list >> Plp...@li... >> https://lists.sourceforge.net/lists/listinfo/plplot-general >> > > ------------------------------------------------------------------------------ > ThinkGeek and WIRED's GeekDad team up for the Ultimate > GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the > lucky parental unit. See the prize list and enter to win: > http://p.sf.net/sfu/thinkgeek-promo |
From: Arjen M. <arj...@de...> - 2010-06-22 07:47:51
|
Hi Alessandro, (I found your message ...) On 2010-06-20 14:04, Alessandro Piras wrote: > The wingcc driver is using obsolete constants: > GCL_HCURSOR > GWL_USERDATA > > that should be replaced by > GCLP_HCURSOR > GWLP_USERDATA > > as in http://msdn.microsoft.com/en-us/library/aa383663.aspx > > I tried to fix it replacing the constants, but It does not work well: > x01c.exe starts, it plots the graphics, and after half a second the > window "the program stopped working appears". > > ... > if ( pls ) > { > dev = (wingcc_Dev *) pls->dev; // This is the offending line (256) > > } > ... > > No idea what's going on, just reporting it :-) I am just guessing here, but the code we are looking at is: pls = (PLStream *) GetWindowLong( hwnd, GWL_USERDATA ); if ( pls ) { dev = (wingcc_Dev *) pls->dev; } Could it be that on Windows 64 we need a _different_ function or functions or macros? This depends crucially on the interpretation of "long". IIRC, long integers are long enough to store void pointers. On 64-bits platforms that means a long is 64 bits, but do we indeed retrieve 64 bits or do we need to use a different function (pair of functions)? A check could be to: - Write the value of pls as stored in SetWindowLong() to the screen as a pointer - Write the value of pls as retrievd from GetWindowLong() to the screen as a pointer. The two should be the same. If not, we know that we have to look for a different set of functions. Regards, Arjen |