Hi Sisyphus,
On 6/21/10 11:48 AM, Sisyphus wrote:
>
> ----- Original Message -----
> From: "Arjen Markus" <[email protected]>
> To: "Sisyphus" <[email protected]>
> Cc: "Alessandro Piras" <[email protected]>;
> <[email protected]>
> 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
> [email protected]
> 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: [email protected] (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
------------------------------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/plplot-general
