5:17 a.m.
Hi,
after quite a while I'm trying to build gretl on Windows again,
following the excellent guide gretl-winbuild.pdf.
The first little problem I came across was inside section 3.5 of the
guide. The command "pacman -S ${DEPS} --needed" (also inside setup.sh)
doesn't work as such, I needed to do (note the y):
pacman -Sy ${DEPS} --needed
If there are more problems, I will post them in this thread (or collect
them first).
thanks
sven
6:19 a.m.
Am 07.11.2019 um 11:17 schrieb Sven Schreiber:
If there are more problems, I will post them in this thread (or
collect
them first).
Ok, so here are various further notes and questions:
1) Is it necessary to add pdflatex to the w32tex installation
(recommended TeX variant in the build guide) ? Currently the configure
step tells me that pdflatex is missing and therefore the documentation
cannot be built. (I have installed w32tex under MSYS following the guide.)
2) In footnote 1 you mention that the Clearlooks theme Gtk DLL was
broken, is that still true? Or rather, how can I test that?
3) A remark for others: Copying & pasting commands from the build guide
sometimes fails because the typographic quotes in there are not the ones
needed on the shell. (Of course copy&paste was never intended.)
Then finally I'd like to follow up on the plan to use GTK3 for the
Windows build. For future reference, to me the paragraph under "Building
and distributing your application" on the page
https://www.gtk.org/download/windows.php sounds promising with respect
to themes and icons. But first the following:
a) I've installed with pacman the packages mingw-w64-x86_64-gtk3 and
mingw-w64-x86_64-gtksourceview3.
b) The configure step works fine, but with make I get this error:
In file included from C:/msys64/mingw64/include/gtk-3.0/gdk/gdkwin32.h:37,
from ../../gretl-git/gui/gretlwin32.c:33:
../../gretl-git/gui/gretlwin32.c: In function 'emf_to_clipboard':
../../gretl-git/gui/gretlwin32.c:393:40: error: 'GtkWidget' {aka 'struct
_GtkWidget'} has no member named 'window'
393 | mainw = GDK_WINDOW_HWND(mdata->main->window);
AFAICS the gretl GUI code for Windows is not GTK3-compatible there, right?
thanks
sven
9:16 a.m.
On Thu, 7 Nov 2019, Sven Schreiber wrote:
Am 07.11.2019 um 11:17 schrieb Sven Schreiber:
> If there are more problems, I will post them in this thread (or collect
> them first).
Thanks for working on this.
Ok, so here are various further notes and questions:
1) Is it necessary to add pdflatex to the w32tex installation
(recommended TeX variant in the build guide) ? Currently the configure
step tells me that pdflatex is missing and therefore the documentation
cannot be built. (I have installed w32tex under MSYS following the guide.)
Hmm, IIRC pdflatex was present by default after installing w32tex. Are
you sure the w32tex/bin directory is in your PATH? (Section 3.1 of my
guide.)
2) In footnote 1 you mention that the Clearlooks theme Gtk DLL was
broken, is that still true? Or rather, how can I test that?
I haven't checked lately. You could try just using the mingw version
instead of the one I've made available, and see if it works. (BTW, I
don't think this will be relevant for GTK 3.)
Then finally I'd like to follow up on the plan to use GTK3 for
the
Windows build. For future reference, to me the paragraph under "Building
and distributing your application" on the page
https://www.gtk.org/download/windows.php sounds promising with respect
to themes and icons. But first the following:
a) I've installed with pacman the packages mingw-w64-x86_64-gtk3 and
mingw-w64-x86_64-gtksourceview3.
b) The configure step works fine, but with make I get this error:
In file included from C:/msys64/mingw64/include/gtk-3.0/gdk/gdkwin32.h:37,
from ../../gretl-git/gui/gretlwin32.c:33:
../../gretl-git/gui/gretlwin32.c: In function 'emf_to_clipboard':
../../gretl-git/gui/gretlwin32.c:393:40: error: 'GtkWidget' {aka 'struct
_GtkWidget'} has no member named 'window'
393 | mainw = GDK_WINDOW_HWND(mdata->main->window);
AFAICS the gretl GUI code for Windows is not GTK3-compatible there, right?
Yep, that's right. It's now fixed in git, I think.
Allin
12:47 p.m.
Am 07.11.2019 um 15:16 schrieb Allin Cottrell:
On Thu, 7 Nov 2019, Sven Schreiber wrote:
Hmm, IIRC pdflatex was present by default after installing w32tex.
Are
you sure the w32tex/bin directory is in your PATH? (Section 3.1 of my
guide.)
Yes, but the installation somehow didn't complete the first time. I
re-ran "wget -N ${RICARDO}/texinst.sh && bash texinst.sh $TEXDIR" and
hope I should be fine now -- yes, it's found now.
But there is another TeX issue: The file 8r.enc isn't found with the
selection of packages in your texinst.sh. I added a bunch of other font
and dvips related packages into the w32tex installation, then it works.
Unfortunately right now I cannot give a minimal necessary set.
(The problem comes from the extra add-on I believe.)
Later (on make install-doc) tikz.sty was missing, so I installed the
pgfcontrib package as well.
> 2) In footnote 1 you mention that the Clearlooks theme Gtk DLL
was
> broken, is that still true? Or rather, how can I test that?
I haven't checked lately. You could try just using the mingw version
instead of the one I've made available, and see if it works. (BTW, I
don't think this will be relevant for GTK 3.)
OK, but your package also bundles other stuff AFAICS, not just the
Clearlooks theme. But agreed, this is not really the topic right now.
> b) The configure step works fine, but with make I get this error:
...
> AFAICS the gretl GUI code for Windows is not GTK3-compatible
there, right?
Yep, that's right. It's now fixed in git, I think.
Yep, looks like, the compilation finished OK it seems - thanks!
Oh, BTW, there were these warnings or "half-errors", don't know how
relevant they might become:
...
LD gretl.exe
libtool: error: Could not determine the host path corresponding to
libtool: error:
'C:/msys64/mingw64/lib:C:/msys64/mingw64/bin:/home/fantomas/src/pkgbuild/lib/.libs:/c/Users/fantomas/gbuild/gretl'
libtool: error: Continuing, but uninstalled executables may not work.
libtool: error: Could not determine the host path corresponding to
libtool: error:
'C:/msys64/mingw64/lib:C:/msys64/mingw64/bin:/home/fantomas/src/pkgbuild/lib/.libs:/c/Users/fantomas/gbuild/gretl'
libtool: error: Continuing, but uninstalled executables may not work.
./mklang > gretl.lang
./mknews ../../gretl-git/ChangeLog > NEWS
...
OK, then I reach the step where install-runtime.sh is executed; of
course there are a lot of hard-coded GTK2 things in there which I am not
tackling right now. But the shell tells me that in line 61 there's a
missing ']':
if [ "x${INSTALL_GNUPLOT}" = "xyes" ; then
So much for now - to be continued....
cheers
sven
1:12 p.m.
Am 07.11.2019 um 18:47 schrieb Sven Schreiber:
So much for now - to be continued....
At this point, running gretl (the GUI program) under MSYS indeed works -
remember this was built with GTK3. However, just like you said the icons
are missing.
So I followed this advice from somewhere on the web:
" you create a directory 'shared' in your build directories, and copy
the icons directory from msys/mingw64/share/ to your build/share directory."
(Where the build dir in my case is C:\Users\<username>\gbuild\gretl.)
And - tadaa - executing "GRETL_HOME=$PREFIX $PREFIX/gretl.exe" indeed
fires up gretl with GTK3 with all the icons and no warning messages on
the console!
So this is looking pretty good so far. The details of the packaging
remain to be sorted out (see previous message), but that shouldn't be a
fundamental problem I guess.
thanks
sven
2:01 p.m.
On Thu, 7 Nov 2019, Sven Schreiber wrote:
Am 07.11.2019 um 18:47 schrieb Sven Schreiber:
> So much for now - to be continued....
At this point, running gretl (the GUI program) under MSYS indeed works -
remember this was built with GTK3. However, just like you said the icons
are missing.
So I followed this advice from somewhere on the web:
" you create a directory 'shared' in your build directories, and copy
the icons directory from msys/mingw64/share/ to your build/share directory."
(Where the build dir in my case is C:\Users\<username>\gbuild\gretl.)
And - tadaa - executing "GRETL_HOME=$PREFIX $PREFIX/gretl.exe" indeed
fires up gretl with GTK3 with all the icons and no warning messages on
the console!
Well done!
Allin
4:40 a.m.
Am 07.11.2019 um 19:12 schrieb Sven Schreiber:
So this is looking pretty good so far. The details of the packaging
remain to be sorted out (see previous message), but that shouldn't be a
fundamental problem I guess.
OK, some remarks or notes-to-self about the created contents of
install-runtime.sh (inside src\pkgbuild\win32\windist) and how it should
be changed for a GTK3 build.
- line 18:
SYSSV=${SYSBASE}/share/gtksourceview-2.0
would need to end in ...-3.0
(BTW, I'm noticing that in the subdir language-specs there's nothing
about gretl/hansl. Should such a language spec be submitted upstream to
GTK, or is it already in newer versions?)
- lines 21-28 together with 71-74:
all the "mdkir" and "cp" actions for gtk-2.0 are probably useless.
The
only supported thing AFAICS would be:
mkdir -p ${TARGET}/share/themes/Default/gtk-3.0
(without "-key")
And in line 72 the file gtkrc apparently becomes gtk-keys.css for GTK3:
cp $SYSTHEME/Default/gtk-3.0/gtk-keys.css
${TARGET}/share/themes/Default/gtk-3.0/gtk-keys.css
- line 32:
Is the given path ${TARGET}/share/locale/$lang/LC_MESSAGES correct in
this context? I see the directory ${TARGET}/locale (without "share"),
but I'm not sure when exactly it was created. -- Ah, but in line 101 I
see some alias being created, so I guess that solves it (?).
- line 42:
libsvm.dll is not present in ${SYSBIN} here.
- lines 76-79:
None of these things seem to have analogues for GTK3? So just remove?
- line 80: replace gtk-2.0 with gtk-3.0
- line 106: replace gtk20.mo with gtk30.mo I guess.
So much for that. Allin, do you think it makes sense to already
incorporate these changes somehow in the source that creates the
install-runtime.sh file (conditional on win32 && GTK3 of course), or
should I first change the created file manually?
thanks
sven
1:55 p.m.
Am 08.11.2019 um 10:40 schrieb Sven Schreiber:
Am 07.11.2019 um 19:12 schrieb Sven Schreiber:
> So this is looking pretty good so far. The details of the packaging
> remain to be sorted out (see previous message), but that shouldn't be a
> fundamental problem I guess.
OK, some remarks or notes-to-self about the created contents of
install-runtime.sh (inside src\pkgbuild\win32\windist)
One further thing - Allin, are you sure that the path specifications are
all correct inside install-runtime.sh? I'm having problems running that,
and if I look at the relative path prefix SRCDIR=../../../gretl-git, I
see that:
First in line 30 it is used before any "cd" happens, so this should be
relative to the location of the shell script, no?
Second in the last line 110 it is invoked after we had a "cd ${TARGET}"
before (in line 99).
I'd say one of these must be wrong, or what am I missing?
thanks
sven
5 p.m.
On Fri, 8 Nov 2019, Sven Schreiber wrote:
Am 08.11.2019 um 10:40 schrieb Sven Schreiber:
> Am 07.11.2019 um 19:12 schrieb Sven Schreiber:
>
>> So this is looking pretty good so far. The details of the packaging
>> remain to be sorted out (see previous message), but that shouldn't be a
>> fundamental problem I guess.
>
> OK, some remarks or notes-to-self about the created contents of
> install-runtime.sh (inside src\pkgbuild\win32\windist)
One further thing - Allin, are you sure that the path specifications are
all correct inside install-runtime.sh? I'm having problems running that,
and if I look at the relative path prefix SRCDIR=../../../gretl-git, I
see that:
First in line 30 it is used before any "cd" happens,
Sorry, but line 30 of what?
so this should be relative to the location of the shell script,
no? Second in the last line 110 it is invoked after we had a "cd
${TARGET}" before (in line 99). I'd say one of these must be
wrong, or what am I missing?
You could be right. The path to SRCDIR in the auto-generated
install-runtime.sh is indeed relative, so probably there should be a
"cd" to its location before executing it, then a "cd" back to
wherever else we ought to be at that point.
I'll have to take a closer look at this myself on Windows.
Allin
4:07 a.m.
Am 08.11.2019 um 23:00 schrieb Allin Cottrell:
On Fri, 8 Nov 2019, Sven Schreiber wrote:
> One further thing - Allin, are you sure that the path
specifications are
> all correct inside install-runtime.sh? I'm having problems running that,
> and if I look at the relative path prefix SRCDIR=../../../gretl-git, I
> see that:
>
> First in line 30 it is used before any "cd" happens,
Sorry, but line 30 of what?
Since you later replied to my other message with line numbers, I'm
assuming that question has been clarified. (Of the generated
install-runtime.sh file. I could post it here if needed.)
> so this should be relative to the location of the shell script,
no?
> Second in the last line 110 it is invoked after we had a "cd
> ${TARGET}" before (in line 99). I'd say one of these must be wrong, or
> what am I missing?
You could be right. The path to SRCDIR in the auto-generated
install-runtime.sh is indeed relative, so probably there should be a
"cd" to its location before executing it, then a "cd" back to
wherever
else we ought to be at that point.
I'll have to take a closer look at this myself on Windows.
OK.
-sven
5:26 p.m.
On Fri, 8 Nov 2019, Sven Schreiber wrote:
Am 07.11.2019 um 19:12 schrieb Sven Schreiber:
> So this is looking pretty good so far. The details of the packaging
> remain to be sorted out (see previous message), but that shouldn't be a
> fundamental problem I guess.
OK, some remarks or notes-to-self about the created contents of
install-runtime.sh (inside src\pkgbuild\win32\windist) and how it should
be changed for a GTK3 build.
- line 18:
SYSSV=${SYSBASE}/share/gtksourceview-2.0
would need to end in ...-3.0
Yes.
(BTW, I'm noticing that in the subdir language-specs there's
nothing
about gretl/hansl. Should such a language spec be submitted upstream to
GTK, or is it already in newer versions?)
It's not in newer versions, and maybe we should submit it upstream.
Though since hansl functions typically grow per release we'd
probably want to rely on our own version anyway so that's not a high
priority.
- lines 21-28 together with 71-74:
all the "mdkir" and "cp" actions for gtk-2.0 are probably useless.
The
only supported thing AFAICS would be:
mkdir -p ${TARGET}/share/themes/Default/gtk-3.0
(without "-key")
And in line 72 the file gtkrc apparently becomes gtk-keys.css for GTK3:
cp $SYSTHEME/Default/gtk-3.0/gtk-keys.css
${TARGET}/share/themes/Default/gtk-3.0/gtk-keys.css
I guess you're right about that.
- line 32:
Is the given path ${TARGET}/share/locale/$lang/LC_MESSAGES correct in
this context? I see the directory ${TARGET}/locale (without "share"),
but I'm not sure when exactly it was created. -- Ah, but in line 101 I
see some alias being created, so I guess that solves it (?).
Not sure I fully understand. We put gtk/glib message catalogs under
share/locale (where they're expected) but put gretl catalogs just
under locale (there being no need for another layer of directory
structure inside a stand-alone package).
- line 42:
libsvm.dll is not present in ${SYSBIN} here.
We don't use that any more -- update needed!
- lines 76-79:
None of these things seem to have analogues for GTK3? So just remove?
Yes, I think so.
- line 80: replace gtk-2.0 with gtk-3.0
Maybe! But I think that may be gone, or may have been moved more
substantially. What it does, I don't know.
- line 106: replace gtk20.mo with gtk30.mo I guess.
So much for that. Allin, do you think it makes sense to already
incorporate these changes somehow in the source that creates the
install-runtime.sh file (conditional on win32 && GTK3 of course), or
should I first change the created file manually?
I'd recommend experimenting with a manual edit of the generated file
first, but if all goes well we can generalize the mechanism for
generating the file. That means modifying both install-runtime.sh.in
and the information it's fed from the configure script.
Allin
4:17 a.m.
Am 08.11.2019 um 23:26 schrieb Allin Cottrell:
On Fri, 8 Nov 2019, Sven Schreiber wrote:
> (BTW, I'm noticing that in the subdir language-specs
there's nothing
> about gretl/hansl. Should such a language spec be submitted upstream to
> GTK, or is it already in newer versions?)
It's not in newer versions, and maybe we should submit it upstream.
Though since hansl functions typically grow per release we'd probably
want to rely on our own version anyway so that's not a high priority.
Right. Personally I'm indeed working with gretl's own editor most of the
time, but I thought that people on Linux perhaps would like to use a
GTK-editor of their own choice, with the correct syntax highlighting.
But I guess we whould wait and see if there's actually demand for that.
> - line 32:
> Is the given path ${TARGET}/share/locale/$lang/LC_MESSAGES correct in
> this context? I see the directory ${TARGET}/locale (without "share"),
> but I'm not sure when exactly it was created. -- Ah, but in line 101 I
> see some alias being created, so I guess that solves it (?).
Not sure I fully understand. We put gtk/glib message catalogs under
share/locale (where they're expected) but put gretl catalogs just under
locale (there being no need for another layer of directory structure
inside a stand-alone package).
Forget it; first I thought it didn't match the existing structure
(because I found the co-existence of share/locale and locale a little
confusing).
> - line 42:
> libsvm.dll is not present in ${SYSBIN} here.
We don't use that any more -- update needed!
Ah, OK.
> - line 80: replace gtk-2.0 with gtk-3.0
Maybe! But I think that may be gone, or may have been moved more
substantially. What it does, I don't know.
(Talking about im-multipress.conf.) Well here on my setup I am actually
seeing the file $SYSBASE/etc/gtk-3.0/im-multipress.conf so that's why I
suggested this change. It is actually the only file in this path/dir.
> So much for that. Allin, do you think it makes sense to already
> incorporate these changes somehow in the source that creates the
> install-runtime.sh file (conditional on win32 && GTK3 of course), or
> should I first change the created file manually?
I'd recommend experimenting with a manual edit of the generated file
first, but if all goes well we can generalize the mechanism for
generating the file. That means modifying both install-runtime.sh.in and
the information it's fed from the configure script.
OK.
thanks,
sven
10:57 a.m.
This is an overall reply to Sven's points about building gretl on
Windows, including building against GTK 3 (GTK 2 being the default
to date).
* I've made a few changes to install-runtime.sh.in and pkgbuild.sh
which hopefully should fix the issues Sven mentioned.
* I've updated the special "deps" packages mentioned in the building
guide. They now include libgsf, which should get used in the build
automatically and should overcome the 4 GB limit on compressed data.
* The gretl-winbuild PDF doc is updated correspondingly.
* I've added to git a template file install-runtime-gtk3.sh.in which
will be used to generate the new file install-runtime-gtk3.sh at
configure time. This is unlikely to be right as it stands, but
hopefully Sven can tweak it. At present you'll have to manually
substitute a call to install-runtime-gtk3.sh in place of
install-runtime.sh. Eventually it should be possible either to make
that selection automatically, or to produce a generalized script
that serves for both GTK 2 and GTK 3.
Allin
7:13 p.m.
Am 09.11.2019 um 16:57 schrieb Allin Cottrell:
This is an overall reply to Sven's points about building gretl
on
Windows, including building against GTK 3 (GTK 2 being the default
to date).
* I've made a few changes to install-runtime.sh.in and pkgbuild.sh which
hopefully should fix the issues Sven mentioned.
Hmm, now I'm getting an error at the 'make' stage (hopefully having
cleaned up sufficiently before re-running more or less from scratch):
LD gretl.exe
libtool: error: Could not determine the host path corresponding to
libtool: error:
'C:/msys64/mingw64/lib:C:/msys64/mingw64/bin:/home/fantomas/src/pkgbuild/lib/.libs:/c/Users/fantomas/gbuild/gretl'
libtool: error: Continuing, but uninstalled executables may not work.
libtool: error: Could not determine the host path corresponding to
libtool: error:
'C:/msys64/mingw64/lib:C:/msys64/mingw64/bin:/home/fantomas/src/pkgbuild/lib/.libs:/c/Users/fantomas/gbuild/gretl'
libtool: error: Continuing, but uninstalled executables may not work.
./mklang > gretl.lang
C:/msys64/home/fantomas/src/pkgbuild/gui/mklang.exe: error while loading
shared libraries: ?: cannot open shared object file: No such file or
directory
make[1]: *** [Makefile:270: gretl.lang] Fehler 127
make[1]: Verzeichnis „/home/fantomas/src/pkgbuild/gui“ wird verlassen
make: *** [Makefile:69: gui] Fehler 2
Somehow the path collection above (2nd libtool line) looks as if the
colon characters are ambiguous or not properly escaped or whatever.
Don't really have an idea where I can change or influence that.
And another thing that came up:
Am I supposed to create the "$HOMEDRIVE$HOMEPATH\\gbuild\\gretl" dir
myself? I did so because it seemed the right thing, but shouldn't it
also be done in the setup script or so?
thanks
sven
7:29 p.m.
Am 10.11.2019 um 01:13 schrieb Sven Schreiber:
Am 09.11.2019 um 16:57 schrieb Allin Cottrell:
> * I've made a few changes to install-runtime.sh.in and
pkgbuild.sh which
> hopefully should fix the issues Sven mentioned.
Hmm, now I'm getting an error at the 'make' stage (hopefully having
cleaned up sufficiently before re-running more or less from scratch):
Strangely enough when simply trying 'make' again it did progress a
little further (how it got over the previous error I don't know), but
then it "sustainably" fails with this:
C:/msys64/home/fantomas/src/pkgbuild/doc/commands/tables.exe: error
while loading shared libraries: ?: cannot open shared object file: No
such file or directory
make[4]: *** [Makefile:284: textables] Fehler 127
This is pretty mysterious at first, but when I manually execute the
tables.exe at the path above I get an error window saying "...
libgsf-1-114.dll couldn't be found...". But I did install your new deps
package with it, and I have:
c:\msys64\mingw64\bin\libgsf-1-114.dll.
Any idea here?
thanks
sven
8:10 a.m.
On Sun, 10 Nov 2019, Sven Schreiber wrote:
Am 10.11.2019 um 01:13 schrieb Sven Schreiber:
> Am 09.11.2019 um 16:57 schrieb Allin Cottrell:
>> * I've made a few changes to install-runtime.sh.in and pkgbuild.sh which
>> hopefully should fix the issues Sven mentioned.
>
> Hmm, now I'm getting an error at the 'make' stage (hopefully having
> cleaned up sufficiently before re-running more or less from scratch):
Strangely enough when simply trying 'make' again it did progress a
little further (how it got over the previous error I don't know), but
then it "sustainably" fails with this:
C:/msys64/home/fantomas/src/pkgbuild/doc/commands/tables.exe: error
while loading shared libraries: ?: cannot open shared object file: No
such file or directory
make[4]: *** [Makefile:284: textables] Fehler 127
This is pretty mysterious at first, but when I manually execute the
tables.exe at the path above I get an error window saying "...
libgsf-1-114.dll couldn't be found...". But I did install your new deps
package with it, and I have:
c:\msys64\mingw64\bin\libgsf-1-114.dll.
Any idea here?
Hmm. In the meantime you can bypass that problem by adding the
option --without-gsf to the script for configuring the build. I'll
have to experiment on Windows to see what's going wrong with the
libgsf linkage.
Allin
1:17 p.m.
Am 10.11.2019 um 14:10 schrieb Allin Cottrell:
On Sun, 10 Nov 2019, Sven Schreiber wrote:
> libgsf-1-114.dll couldn't be found...". But I did
install your new deps
> package with it, and I have:
> c:\msys64\mingw64\bin\libgsf-1-114.dll.
Hmm. In the meantime you can bypass that problem by adding the
option
--without-gsf to the script for configuring the build. I'll have to
experiment on Windows to see what's going wrong with the libgsf linkage.
Hi,
I have now successfully produced a snapshot installer exe (although the
result is untested), but there are a couple of caveats still:
* The unsettled gsf issue from above (I followed your config suggestion
to simply ignore it).
* In install-runtime-gtk3.sh I had to apply the following changes:
- rename libgailutil-3.dll to libgailutil-3-0.dll
- comment out the immodules line, because there aren't any dll's in the
referenced dir (will that be a problem later on in using the program?)
* In mkdist.sh I needed to point to "Inno Setup 6" instead of 5; this is
obviously related to my newly installed version, but I just followed the
instructions in the guide (section 6), so I guess it could be updated.
* In win32/windist/isstop.64 I needed to comment out the use of Greek as
a language because that didn't work for me. I suspect this could be
solved by installing Greek language support on this Windows 10 system,
but I haven't tried yet. (OTOH Japanese is also specified there and that
didn't cause any problems, although I'm pretty sure I don't have that
installed. So maybe there's something else going on.)
* I'm repeating my open question whether ..../gbuild/gretl needs to be
created manually before the whole process.
Thanks,
Sven
4:14 p.m.
Am 10.11.2019 um 19:17 schrieb Sven Schreiber:
Hi,
I have now successfully produced a snapshot installer exe (although the
result is untested), but there are a couple of caveats still:
* The unsettled gsf issue from above (I followed your config suggestion
to simply ignore it).
* In install-runtime-gtk3.sh I had to apply the following changes:
- rename libgailutil-3.dll to libgailutil-3-0.dll
- comment out the immodules line, because there aren't any dll's in the
referenced dir (will that be a problem later on in using the program?)
* In mkdist.sh I needed to point to "Inno Setup 6" instead of 5; this is
obviously related to my newly installed version, but I just followed the
instructions in the guide (section 6), so I guess it could be updated.
* In win32/windist/isstop.64 I needed to comment out the use of Greek as
a language because that didn't work for me. I suspect this could be
solved by installing Greek language support on this Windows 10 system,
but I haven't tried yet. (OTOH Japanese is also specified there and that
didn't cause any problems, although I'm pretty sure I don't have that
installed. So maybe there's something else going on.)
* I'm repeating my open question whether ..../gbuild/gretl needs to be
created manually before the whole process.
P.S.: I forgot the original point about the missing icons, so what still
needs to be added to the packaging process is:
"...copy the icons directory from msys/mingw64/share/ to your
build/share directory."
(Where the build dir in my case is C:\Users\<username>\gbuild\gretl
cheers
sven
5:20 p.m.
On Sun, 10 Nov 2019, Sven Schreiber wrote:
P.S.: I forgot the original point about the missing icons, so what
still
needs to be added to the packaging process is:
"...copy the icons directory from msys/mingw64/share/ to your
build/share directory."
(Where the build dir in my case is C:\Users\<username>\gbuild\gretl
Is that the entire content of msys/mingw64/share/icons ?
Allin
5:49 p.m.
Am 10.11.2019 um 23:20 schrieb Allin Cottrell:
On Sun, 10 Nov 2019, Sven Schreiber wrote:
> P.S.: I forgot the original point about the missing icons, so what still
> needs to be added to the packaging process is:
> "...copy the icons directory from msys/mingw64/share/ to your
> build/share directory."
> (Where the build dir in my case is C:\Users\<username>\gbuild\gretl
Is that the entire content of msys/mingw64/share/icons ?
Well, it's a lot in terms of MB, and probably not everything is needed.
But which files must be copied remains to be checked, or do you have a
list? So far for the local test build I just copied the whole thing for
simplicity.
cheers
sven
6:41 a.m.
Am 10.11.2019 um 23:49 schrieb Sven Schreiber:
Am 10.11.2019 um 23:20 schrieb Allin Cottrell:
> On Sun, 10 Nov 2019, Sven Schreiber wrote:
>
>> "...copy the icons directory from msys/mingw64/share/ to your
>> build/share directory."
>> (Where the build dir in my case is C:\Users\<username>\gbuild\gretl
>
> Is that the entire content of msys/mingw64/share/icons ?
Well, it's a lot in terms of MB, and probably not everything is needed.
But which files must be copied remains to be checked, or do you have a
list? So far for the local test build I just copied the whole thing for
simplicity.
I'm going to look at the contents of that icon dir in more detail, but
cannot do so before Thursday. One thing one notices already is that
there are a bunch of subdirs for different pixel dimensions (say,
128x128 or so). Would gretl need every size it can get a hold on, or are
only specific sizes used?
thanks
sven
5:06 p.m.
On Sun, 10 Nov 2019, Sven Schreiber wrote:
Am 10.11.2019 um 14:10 schrieb Allin Cottrell:
> On Sun, 10 Nov 2019, Sven Schreiber wrote:
>> libgsf-1-114.dll couldn't be found...". But I did install your new deps
>> package with it, and I have:
>> c:\msys64\mingw64\bin\libgsf-1-114.dll.
> Hmm. In the meantime you can bypass that problem by adding the option
> --without-gsf to the script for configuring the build. I'll have to
> experiment on Windows to see what's going wrong with the libgsf linkage.
Hi,
I have now successfully produced a snapshot installer exe (although the
result is untested), but there are a couple of caveats still:
* The unsettled gsf issue from above (I followed your config suggestion
to simply ignore it).
I'll get to that before too long.
* In install-runtime-gtk3.sh I had to apply the following changes:
- rename libgailutil-3.dll to libgailutil-3-0.dll
OK, I'll revise install-runtime-gtk3.sh.in accordingly.
- comment out the immodules line, because there aren't any
dll's in the
referenced dir (will that be a problem later on in using the program?)
No, I don't think it'll be a problem.
* In mkdist.sh I needed to point to "Inno Setup 6" instead
of 5; this is
obviously related to my newly installed version, but I just followed the
instructions in the guide (section 6), so I guess it could be updated.
Yes, indeed.
* In win32/windist/isstop.64 I needed to comment out the use of Greek
as
a language because that didn't work for me. I suspect this could be
solved by installing Greek language support on this Windows 10 system,
but I haven't tried yet.
I think it has to do with what translations are available in the
Inno Setup package, not Windows itself. IIRC I added a "beta"
translation on my system and maybe that was Greek.
* I'm repeating my open question whether ..../gbuild/gretl needs
to be
created manually before the whole process.
Yes, there's nothing in the scripts to create that. I should make
that clear in the PDF.
Allin
6:03 p.m.
On Sun, 10 Nov 2019, Allin Cottrell wrote:
On Sun, 10 Nov 2019, Sven Schreiber wrote:
> * I'm repeating my open question whether ..../gbuild/gretl needs to be
> created manually before the whole process.
Yes, there's nothing in the scripts to create that. I should make that clear
in the PDF.
Maybe better: I've amended pkgconf.sh so that it ensures the
"PREFIX" directory gets created.
Allin
2:54 a.m.
Am 11.11.2019 um 00:03 schrieb Allin Cottrell:
Maybe better: I've amended pkgconf.sh so that it ensures the
"PREFIX"
directory gets created.
Thanks. Would it be an option to put these shell scripts into git, too?
It's not totally clear to me why install-runtime-gtk3.sh.in is in git
but things like pkgconf.sh aren't.
thanks
sven
6:36 p.m.
On Mon, 11 Nov 2019, Sven Schreiber wrote:
Am 11.11.2019 um 00:03 schrieb Allin Cottrell:
> Maybe better: I've amended pkgconf.sh so that it ensures the "PREFIX"
> directory gets created.
Thanks. Would it be an option to put these shell scripts into git, too?
It's not totally clear to me why install-runtime-gtk3.sh.in is in git
but things like pkgconf.sh aren't.
Possible, yes, but a bit awkward. The existing "*.in" files in git
are used to generate shell scripts or Makefiles in the user's build
directory, based on information/options supplied by the user at
configure time.
My pkgconf.sh, on the other hand, is a suggestion for what the user
might pass to gretl's configure script -- in the highly unlikely
event that he or she is aiming to build a redistributable gretl
package on MS Windows!
We could, I guess, add to git a special "pkgbuild" directory under
"win32" in the source tree, holding some or all of the
package-building scripts. But no auto-generated counterparts would
appear in the user's build directory, such scripts being prior to
"configure".
Allin
5:52 a.m.
Am 12.11.2019 um 00:36 schrieb Allin Cottrell:
On Mon, 11 Nov 2019, Sven Schreiber wrote:
My pkgconf.sh, on the other hand, is a suggestion for what the user
might pass to gretl's configure script -- in the highly unlikely event
that he or she is aiming to build a redistributable gretl package on
MS Windows!
We could, I guess, add to git a special "pkgbuild" directory under
"win32" in the source tree, holding some or all of the
package-building scripts. But no auto-generated counterparts would
appear in the user's build directory, such scripts being prior to
"configure".
The latter is basically what I meant, maybe accompanied by a README
saying that the contents of the package building scripts are just
suggestions and refer to the pdf guide. (Also with respect to the used
TeX distro, for example.)
But if the current (mild) server fragmentation doesn't bother you, maybe
just leave it as is.
cheers
sven
2 p.m.
On Thu, 7 Nov 2019, Sven Schreiber wrote:
Am 07.11.2019 um 15:16 schrieb Allin Cottrell:
> On Thu, 7 Nov 2019, Sven Schreiber wrote:
> Hmm, IIRC pdflatex was present by default after installing w32tex. Are
> you sure the w32tex/bin directory is in your PATH? (Section 3.1 of my
> guide.)
Yes, but the installation somehow didn't complete the first time. I
re-ran "wget -N ${RICARDO}/texinst.sh && bash texinst.sh $TEXDIR" and
hope I should be fine now -- yes, it's found now.
But there is another TeX issue: The file 8r.enc isn't found with the
selection of packages in your texinst.sh. I added a bunch of other font
and dvips related packages into the w32tex installation, then it works.
Unfortunately right now I cannot give a minimal necessary set.
(The problem comes from the extra add-on I believe.)
Later (on make install-doc) tikz.sty was missing, so I installed the
pgfcontrib package as well.
I've now added dvipsk-w32 pgfcontrib txpx-pazofonts to the package
listing. I think that should cover it.
> > 2) In footnote 1 you mention that the Clearlooks theme Gtk
DLL was
> > broken, is that still true? Or rather, how can I test that?
>
> I haven't checked lately. You could try just using the mingw version
> instead of the one I've made available, and see if it works. (BTW, I
> don't think this will be relevant for GTK 3.)
OK, but your package also bundles other stuff AFAICS, not just the
Clearlooks theme.
True, but you could install the gtk-engines package on top of my stuff
and it should just replace Clearlooks.
> > b) The configure step works fine, but with make I get this
error:
...
> > AFAICS the gretl GUI code for Windows is not GTK3-compatible there, right?
>
> Yep, that's right. It's now fixed in git, I think.
Yep, looks like, the compilation finished OK it seems - thanks!
Good to hear!
OK, then I reach the step where install-runtime.sh is executed; of
course there are a lot of hard-coded GTK2 things in there which I am not
tackling right now. But the shell tells me that in line 61 there's a
missing ']':
if [ "x${INSTALL_GNUPLOT}" = "xyes" ; then
A straightforward bug, now fixed in git.
Allin
11:12 a.m.
On Thu, 7 Nov 2019, Sven Schreiber wrote:
Hi,
after quite a while I'm trying to build gretl on Windows again,
following the excellent guide gretl-winbuild.pdf.
The first little problem I came across was inside section 3.5 of the
guide. The command "pacman -S ${DEPS} --needed" (also inside setup.sh)
doesn't work as such, I needed to do (note the y):
pacman -Sy ${DEPS} --needed
I've added the 'y' to the script in question and the guide text. While
I was at it I updated the gnuplot builds available in package and
tar.gz forms.
Allin
1832
days inactive
1837
days old
27 comments
2 participants
participants (2)
-
Allin Cottrell -
Sven Schreiber