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 |