I'm trying a 64-bit build of plplot-5.9.6 on Vista64 using the mingw64
In winuser.h, the symbols GWL_USERDATA and GCL_HCURSOR are undef'd if _WIN64
is defined - and replaced by GWLP_USERDATA and GCLP_HCURSOR respectively.
I've therefore inserted the following code into drivers/wingcc.c (a few
lines down from the top, immediately after the inclusion of <windows.h>).
#define GWL_USERDATA GWLP_USERDATA
#define GCL_HCURSOR GCLP_HCURSOR
That seems to work fine, but there are other problems.
As with the 32-bit build, I'm building static libs. Running mingw32-make,
all goes ok until:
[100%] Building C object utils/CMakeFiles/pltek.dir/pltek.c.obj
Linking C executable pltek.exe
C:\Windows\SysWOW64\gdi32.dll: file not recognized: File format not
collect2: ld returned 1 exit status
mingw32-make: *** [utils/pltek.exe] Error 1
mingw32-make: *** [utils/CMakeFiles/pltek.dir/all] Error 2
mingw32-make: *** [all] Error 2
It *should* be trying to link to the compiler library
C:\_64\mingw64\mingw\lib\libgdi32.a instead of the system dll. (At least
that's what happens when I build the same source in the same way with the
32-bit mingw compiler.)
I have an idea of what the problem might be. With 32-bit mingw, the
compiler's standard libraries (relative to the bin folder) are located in
../lib. But with the 64-bit mingw compiler the relationship is ../mingw/lib.
I'm wondering if there's something hardcoded in the plplot sources that
assumes the former ... and that the attempt to link to the system dll's
might be a fallback when the compiler libs aren't found. There is a ../lib
folder already existent. It's empty, except for a folder named 'gcc'. If I
copy libgdi32.a and libcomdlg32.a to that lib folder, then the build
succeeds - so I'm thinking that my appraisal of the situation has some
merit. I just need to learn how to fix it correctly.
Also, is there any way to tell the build process that the c and c++ compiler
executables are not called simply gcc.exe and g++.exe ? With the x64 mingw
compiler that I'm using (actually a cross-compiler), the names of those
executables (along with ar, strip, ranlib, dlltool, etc.) are all prefixed
with 'x86_64-w64-mingw32-'. I've worked around the problem by cheating and
creating copies of the gcc, g++ and ar executables, with the prefix
removed - but it would be preferable if that could be avoided.
Anyway, with all that done, plplot-5.9.6 builds fine - the c and c++
examples look correct in the wingcc window.
For some reason I had to copy w64gcc_s_sjlj-1.dll and libstdc++-6.dll to the
examples/c++ directory in order for the c++ examples to run.