#163 building instructions for native win32/64
Although the gnuplot code itself compiles successfully using visual c, all the cairo terminals as well as png, jpeg, etc. using gdlib cannot be done without a lot of previous experience. This is mostly because those libraries, too, have very little/outdated build instructions for vc.
Also there is no information available on the packaging for the windows installer that has been used in the past, so that someone could volunteer to make an installer for gp4.6.4 without re-inventing the whole thing.
And the build instructions don´t say anything about the recommended (or last known-to-work) versions of all the libraries, so that one could first try those before attempting to update them. For example gdlib has a new version 2.1.0, while the recommended binary of the earlier version has vanished from the web.
I fear if this keeps up, gnuplot might loose the ability to work under windows at all.
In the recent past, official binary builds were been done by Tatsuro Matsuoka and me. We both use MinGW (not MinGW-w64). FWIW you can find a recent build of the 4.6 branch at
http://www.gnuplot.info/development/binaries/
This package also includes a list of libraries (and where to get them) which where used for the build, see the attached README-testing.txt.
As to MinGW building instructions: Most of this is actually rather straight forward (but a lot more more than on *nix). Yves Surrel previously did a nice write-up of his build procedure, but I am not sure that this is publicly available. I am attaching my own (somewhat outdated) instructions, which describe my previous setup used for the 4.6.3 build. I am willing to update the instructions to my current setup in the next few days.
As far as Visual C is concerned, doing a full featured build which includes the gd terminals and the cairo/pango/wxt terminals is indeed somewhat tricky, but feasible. It requires compiling quite a few prerequisite libraries. If helpful, I can provide some information on how to build libgd and cairo/pango, too.
Ticket moved from /p/gnuplot/bugs/1320/
OK, I didn´t realize the official build was done using MinGW.
So probably nobody knows whether the vc build still does work, right?
I might give it a try one of these days. Much of the information on MinGW will surely apply there too, i guess, so that will be some help.
Oh, what are the pros and cons of using vc against MinGW? Should i just say "why bother with microsoft"?
Building with VC should work just fine. The Makefile in config/msvc is still maintained and a number of people seem to do builds using it. Recently, e.g. Thomas Bleher started working on Windows support for the QT terminal, see
https://sourceforge.net/p/gnuplot/patches/645/
In fact, I do most of my gnuplot development using MSVC - compiling is much faster and the IDE and the debugger are great. It's just that builds which require a lot of external dependencies like cairo/pango are really tedious since everything has to be built from source and not all libraries have great support for Windows. For cairo/pango/glib the attached link list might get you started.
If you build using MSVC you might want to include this patch, too:
https://sourceforge.net/p/gnuplot/patches/484/
OK, that all sounds quite encouraging. I was a bit dismayed because 4.6.4 has been out for two months and there´s still no official binary. ;-)
I´ll get back here as soon as i get round to giving it another try myself.
Here's the promised update to my building instructions with MinGW.
I can´t make libcerf-1.3, it first gives a warning about undefined symbols not being allowed in i686-pc-mingw32 shared libraries, and a few steps later stops in "./test", complaining about several undefined references to
cexp.Does my mingw miss some needed library? I just installed the basic setup, i.e. mingw32-base, - developer-toolskit, -gcc-g++ & msys-base
Funnily, the incomplete build of libcerf can be installed, and works.
When i tried to compile gnuplot/mingw with libcerf disabled however, there was an error in the first try. Unfortunately i don´t remember the exact reason (something with cerf and dawson), and it´s not reproducible now, even after issuing "make clean". Well.
I´ve now build the current 50alpha from cvs, and got everything except pdf, wxt and caca.
gp465 also compiles (everything except pdf and wxt).
wxt will compile overnight, let´s see ...
The instructions in mingw-gnuplot.txt are very helpful, thanks. It should be added that libiconv is also in the gtk+-bundle.
If it is not installed, make stops at the japanese help file, complaining about a missing libintl-8.dll. Sothe making of the jp help file should probably depend on ICONV=1 and/or have it´s own definition line in the first part of the makefile.(iconv.exe is from mingw, and needs the appropriate mingw-libintl package, but works with libintl from the gkt+-bundle, too.)
Last edit: Karl Ratzsch 2014-06-02
wxWidgets2812MSW won´t compile under mingw. It stops at the same error as in those two links:
http://stackoverflow.com/questions/19476533/error-while-compiling-wxwidgets-2-8-12-on-mingw-with-gcc-4-8-1
http://trac.wxwidgets.org/ticket/15537
answers there say that it´s an error in mingw, an recommend using MinGW-w64. Hm.
Attached to this tracker are now updated building instructions which also include the qt terminal.
I had to replace all 8 occurences of "TV_DISPINFO" in wxWidgets/src/msw/treectrl.cpp by "NMTVDISPINFO", see link to trac/wxwidgets.org above. Now wxwidgets2812 compiles with mingw32. "make install-strip" complains about a missing wxmse28u_gcc_custom.dll.
And gnuplot5.1-cvs also compiles, with wxt enabled, and it seems to work! I was just able to try out the new save/export buttons. :-)
Congrats. I just checked but couldn't identify any changes in my wxWidgets source tree. Somehow the version of MinGW I used last time still compiled the original source. Of course we could now just add "-DTV_DISPINFO=NMTVDISPINFO" to CFLAGS.
The mingw Makefile says
# If libgd has been compiled with TrueType font support, then you can use
# scaled TrueType fonts. If not, then uncomment FREETYPE.
Does libgd-2.1 (latest is 2.1.1) always have TrueType font support? I see no way to dis-/enable it. Are there any (dis-)advantages to using the one or the other?