Am 20.03.2020 um 10:31 schrieb Sven Schreiber: OK here's what I did. I already have MSYS/MinGW installed (64bit). I deleted the old /opt/gretl and ~/src/build. In ~/src/gretl-git I did git pull. I deleted ~/pkglist.sh, ~/add-repo.sh, and ~/setup.sh. I ran pacman -Syu (which produced quite a bit of updates). I did not delete the texinst shell script in the hope that this time-consuming step could be avoided. I re-downloaded setup.sh as per the wget command in the guide and ran: bash setup.sh. (Mingw's openblas and curl conflict with the gretl deps package and have to be removed along the way. This is a bit of a problem -but not major- when you also do other stuff with this MSYS instance, you always have to flip back and forth. But that's not the point right now.) Then ran make inside ~/src/build. (But this is with the default GTK2. The aim is to build with GTK3 afterwards.) This gives the following error: ../../gretl-git/lib/src/gretl_foreign.c:39:11: fatal error: Rinternals.h: No such file or directory 39 | # include <Rinternals.h> /* for SEXP and friends */ | ^~~~~~~~~~~~~~ compilation terminated. Then I ran 'make clean' inside ~/src/build and added to conf.sh the additional switch --with-libR=no. I got some warning about being unable to build docs because XSLT or pdflatex not found. I ran make again nonetheless. Then I get this error: ../../gretl-git/lib/src/gretl_mpi.c:23:10: fatal error: mpi.h: No such file or directory 23 | #include <mpi.h> | ^~~~~~~ compilation terminated. OK, so again 'make clean' and added --with-mpi=no to conf.sh. The build then finished without errors! (Didn't try installing etc.) Now back to the GTK3 issue: Ran make clean again and deleted the --enable-gtk2 line from conf.sh. The make stage is still running (building on MSYS seems quite a bit slower than on Linux). Will report back thanks sven

On Wed, 25 Mar 2020, Sven Schreiber wrote: Clearly this did not fully work. You're missing (at least part) of the content of the the gretl-x86_64-deps package from the pacman repository at sourceforge. That package includes the R and mpi headers that your build is missing. See section 3.5 of "Building gretl on MS Windows". Perhaps I should offer a split of the gretl-x86_64-deps package, leaving out openblas and curl so people could just use the mingw64 versions. The reasons I've not done that to date are: * Openblas should really be multi-threaded via OpenMP for use with gretl, but the mingw64 package uses raw pthreads. * The mingw64 curl package is fine, but it's full-featured and drags in as dependencies a lot of DLLs that gretl has no use for. The curl in my package is slimmed down to what gretl actually needs. This has more relevance if you're building gretl for distribution rather than just for your own use. Allin

Am 25.03.2020 um 23:01 schrieb Sven Schreiber: OK, there was a dependency issue so indeed the deps package wasn't installed. I had to remove three other packages manually to clear the way for openblas and curl to be removed. Maybe it would be better to error out in such cases instead of continuing in the shell script. Then the build process (with R, MPI, doc and addons) looked good initially, but towards the end I got a file not found error from pdflatex. It seemed to look for /opt/gretl/<something> when that path didn't exist yet (prior to installation). Could it be that one has to first make a more minimal build&install and then do a second pass with more build options, when the install prefix dir already exists? thanks sven

On Thu, 26 Mar 2020, Sven Schreiber wrote: That may be ugly but it's harmless. Hmm, what does "No such file or directory" refer to, exactly? If it's pdflatex itself, then see section 3.1 of the building guide: export PATH=$PATH:/c/w32tex/bin # or whatever (but in that case I'd expect to see "Command not found"). Or is it gretl-ref.tex that's not found? If so, I think I see why that might be (an instance of no symlinks on Windows breaking the build) and I can try revising doc/tex/Makefile. Allin

On Thu, 26 Mar 2020, Sven Schreiber wrote: There's now an attempted fix in git -- a revision of doc/tex/Makefile.in. Tested on Linux but not yet on Windows. Allin

On Fri, 27 Mar 2020, Sven Schreiber wrote: OK, I saw that too on blowing away doc/tex and starting over. In git there's another revision of the Makefile.in files in both the commands and tex subdirectories of doc. A from-scratch build now works OK for me on Linux, I hope it'll work on Windows. Allin

On Fri, 27 Mar 2020, Sven Schreiber wrote: Oh god, this is so fiddly! Another Makefile.in revision is now in git. (I presume you've got this OK, but when any Makefile.in is modified, the configure script must be re-run to get the Makefiles updated.) Allin

Am 28.03.2020 um 08:45 schrieb Sven Schreiber: This time I "only" deleted the build directory and re-ran the setup.sh which also re-configures. Unfortunately, exactly the same message as above. thanks sven

On Sat, 28 Mar 2020, Sven Schreiber wrote: I've had another go at the Makefiles, which might help, but if it still doesn't work I'll need some more information to identify the error. If the pdflatex executable itself is found OK there should be some message from it. If the tex file on the command line (say, "foo.tex") is missing there should be something like: ! I can't find file `foo.tex'. If foo.tex is present but some included file is not found, there should be a log file foo.log which identifies the error. Allin

On Sun, 29 Mar 2020, Sven Schreiber wrote: In your build/addons/SVAR directory, what's the value of "topsrc" on the first line? And in the same directory, what do the first few lines of pkg.inp look like? If I'm normalizing the funny-looking path above correctly, it resolves to C:/msys64/home/fantomas/src/build/gretl-git/addons/SVAR/SVAR_boot.inp which looks wrong: "build" shouldn't be in there? Allin

On Sun, 29 Mar 2020, Sven Schreiber wrote: Ah, that must be due to the trailing backslash in the first part of the path. And I can guess what needs to be fixed to handle that. Stay tuned! Allin

Am 30.03.2020 um 18:20 schrieb Allin Cottrell: Ahhh, excellent work Allin! Now for the first time I'm able to build flawlessly with addons (and also GTK3) on Windows. Fyi, here's the modified conf.sh that I'm using: # Sample driver for gretl's configure script, to build # on MS Windows under msys2/mingw64. This version uses # a unix-type file layout; for a version that can be # used to produce a standalone package, see pkgconf.sh RLIB_CFLAGS="-I${MSYSTEM_PREFIX}/lib/R/include" \ MPICC=gcc MPILINK="-lmsmpi" \ LAPACK_LIBS="-lopenblas -lgfortran" \ ../gretl-git/configure --prefix=/opt/gretl \ --disable-gnuplot-checks \ --enable-build-doc \ --enable-quiet-build \ --with-odbc \ --enable-build-addons # --enable-gtk2 \ In the upcoming days I'll try to build the installer package. thanks a lot, sven

On Tue, 31 Mar 2020, Sven Schreiber wrote: Right. We never quite resolved that, to date, but it seems that using GTK3 rather than GTK2 requires a BIG additional load of icon files -- exactly how big remains to be determined. In the GTK2 case the icons are built-in; with GTK3 they need to be added per theme. Allin

On Wed, 1 Apr 2020, Sven Schreiber wrote: Try looking at https://stackoverflow.com/questions/28953925/glib-gio-error-no-gsettings-... Allin

Am 01.04.2020 um 16:45 schrieb Sven Schreiber: I copied from C:\msys64\mingw64\share\glib-2.0\schemas the files: org.gtk.Settings.ColorChooser.gschema.xml org.gtk.Settings.FileChooser.gschema.xml gschemas.compiled to C:\Program Files\gretl\share\glib-2.0\schemas (after creating that dir) and that solved the problem described above. thanks sven