By the way, I can compile Tcl/Tk on Windows and also GST 3.1 on Linux without a problem.

This patch should fix part of the OpenGL build, but unfortunately not fully.

--- a/packages/opengl/gstopengl.h
+++ b/packages/opengl/gstopengl.h
@@ -56,6 +56,10 @@
 #include "config.h"
 #include "gstpub.h"
 
+#if defined __MSVCRT__ || defined __CYGWIN__ || defined __CYGWIN32__ || defined WIN32 || defined _WIN32 || defined __WIN32__
+#include <windows.h>
+#endif
+
 #include GL_GL_H
 #include GL_GLU_H
 
--- a/build-aux/gl.m4
+++ b/build-aux/gl.m4
@@ -9,7 +9,7 @@ AC_CACHE_CHECK([how to link with OpenGL libraries], gst_cv_opengl_libs, [
   if test $ac_cv_header_OpenGL_gl_h = yes || \
      test $ac_cv_header_GL_gl_h = yes; then
     case $host in
-      *-*-mingw* | *-*-cygwin*) gst_cv_opengl_libs='' ;;
+      *-*-mingw* | *-*-cygwin*) gst_cv_opengl_libs='-lopengl32 -lgdi32' ;;
       *-*-beos* | *-*-qnx*) gst_cv_opengl_libs='-lGL' ;;
       *-*-darwin*) gst_cv_opengl_libs='-Wl,-framework,OpenGL' ;;
       *) gst_cv_opengl_libs='-lGL -lGLU $(X_LIBS) $(X_PRE_LIBS) -lX11' ;;

Please use make >error.log 2>&1, it is very hard to figure out these problems without seeing the first errors.

Now I used:

$ gst_cv_opengl_libs='not found' ./configure --with-tcl=/home/Canol/tcl8.4.19/win --with-tk=/home/Canol/tk8.4.19/win

and the errors in the attachement occured while compiling.

This failure is already fixed in the git tree.

Can you check if the other patch fixes building the OpenGL bindings?

Thanks!

Ups, master git release requires autoconf and I don't have it on Windows. It is another pain to install it on Windows (here are installation instructions for those who wants to try: http://www.mingw.org/wiki/MSYS). I guess I won't be able to install it (time time time)... You can add this to the reasons why it would be better for me to have a moderner building system than autotools for GST :)

No problem. You can apply the build-aux/gl.m4 part of the patch directly to the configure script (and of course you also need to apply the other part to packages/opengl/gstopengl.h). Also, you could apply only the packages/opengl/gstopengl.h part to see if at least it fixes compilation (it will then fail linking without the other part).

I'll provide a test tarball one of this days, but I'd like to first iron out the OpenGL issue.

Applied the patches manually but same error occured, log is in the attachment.

Not that it would have changed anything, but have you applied the build-aux/gl.m4 part to configure? I see

checking how to link with OpenGL libraries... 

which is wrong. Also, can you find the GL/gl.h file and send it to me privately? Thanks!

I opened build-aux/gl.m4 file and changed:

*-*-mingw* | *-*-cygwin*) gst_cv_opengl_libs='' ;;

line to:

*-*-mingw* | *-*-cygwin*) gst_cv_opengl_libs='-lopengl32 -lgdi32' ;;

I will send that file in a second to your mail.

No, that part must be applied to configure if you don't want to install Autoconf.

I once again give up, changed configure file but again a similar warning. This time it gave the error very early though. Error in the attachment.

I should learn autotools first.

I fixed OpenGL to build (I don't yet know if it works).

Problems now include:
1) gst's read-eval-print-loop does not work under msys terminal (rxvt) because its stdin is a pipe.

2) i couldn't get a working zip under msys. i'll probably add a "minizip" program to remove the InfoZIP dependency and, at the same time, fix this bug (using Smalltalk only would be slow because of CRC32 calculations).

3) gst-tool seems to work only under rxvt, otherwise it hangs (I cannot even get a backtrace though).

4) there are other problems, which i'll fix first, due to msys not handling paths with mixed path separators.

Things are not as bad as this comment may suggest though.

sub-issue 4 is fixed in trunk.

Hi,

I've downloaded the sources from http://git.savannah.gnu.org/cgit/smalltalk.git/snapshot/smalltalk-master.... Autoreconf worked fine make fails when trying to run libgst/genbc.exe:

...
make[2]: Leaving directory `/home/stef/temp/smalltalk-master/snprintfv'
Making all in libgst
make[2]: Entering directory `/home/stef/temp/smalltalk-master/libgst'
make[3]: Entering directory `/home/stef/temp/smalltalk-master/libgst'
make[3]: `genbc.exe' is up to date.
make[3]: Leaving directory `/home/stef/temp/smalltalk-master/libgst'
./genbc ./byte.def ./byte.c ./opt.c ./xlat.c > match.h
make[2]: *** [match.stamp] Error 5
make[2]: Leaving directory `/home/stef/temp/smalltalk-master/libgst'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/stef/temp/smalltalk-master'
make: *** [all] Error 2

Using GDB:

$ gdb genbc.exe
GNU gdb 6.8
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-pc-mingw32"...
(gdb) run
Starting program: d:\msys\1.0\home\stef\temp\smalltalk-master\libgst/genbc.exe
[New thread 4956.0xc7c]
Usage: genbc ...

Program exited with code 01.
(gdb) set args a b
(gdb) run
Starting program: d:\msys\1.0\home\stef\temp\smalltalk-master\libgst/genbc.exe a b
[New thread 2776.0xa40]

Program received signal SIGSEGV, Segmentation fault.
0x7c90100b in ntdll!RtlEnumerateGenericTableLikeADirectory ()

  from C:\WINDOWS\system32\ntdll.dll

Any idea?

It is now July 2009 and it appears that few Smalltalkers build GST on Windows XP.
But most of corporate is still standardized on Windows. And I am only interested in GST to try an alternate web framework (Iliad).
If I wanted to spend my time on the command line there is more work to be had in Ruby ...
And I left C and C++ programming behind when I last ahd to build my own DLL for a commercial Smalltalk over a decade ago.
I also work in Rebol which is written in C. But most Rebol developers do not work in C.
If Io catches on, most Io developers will work in Io, not in C.

It seems an obvious point - but since most of the tools that I build which use Tcl and or Tk build fine with either my Msys or my Cygwin, that something is not quite right in Gst. Having the latest msingw and the latest Msys changes nada. Common tools build (tcl and tk among them) - but GST does not.

This was true a few years back - but I thought that something might have changed.

Is there a single Windows XP SP3 user doing a build of GST without having VC++ or Visual Studio in their path? (any run of a Makefile on Windows that croaks on having an emacs ENV var set has that fishy MS smell to it ... Bill Gates never learned Smalltalk, Prolog, Lisp or Emacs - and he's younger than me.) And the mingw OpenGL comes with an Imakefile which means not autoconf although I thought GST was moving to autoconf.

I own a domain called make-config.net and started blogging as eclectic-pencil only because of these "we neglected to mention" join-the-club hazings which - well - build character if not tools ...

So why do so few people who want to USE Tk have to build Tcl/tk for Windows these days? For that matter, why does Steve Balmer not blame users for failing to compile cmd.exe with VS before complaining about bugs? And those DLL's in /system32 - are they the latest build?

Thoroughly vexed...

Cross-compiling now works. GNU Smalltalk REPL works from a cmd.exe console, but hangs while loading packages.

The minizip program is not there yet, but when crosscompiling you can at least use a Unix zip.

The issue of comment #15 has been fixed too.

Hi Paolo,

I re-downloaded the sources from http://git.savannah.gnu.org/gitweb/?p=smalltalk.git;a=snapshot;h=433a360... (master).
"libgst/genbc.exe" is still not working:


$ gdb genbc.exe
GNU gdb 6.8
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-pc-mingw32"...
(no debugging symbols found)
(gdb) set args a b
(gdb) run
Starting program: d:\msys\1.0\home\stef\temp\smalltalk\libgst/genbc.exe a b
[New thread 3268.0xa88]
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)

Program exited with code 030000000005.

I am using autoconf-2.63, automake-1.11, libtool-2.2.6 on WindowsXP, SP3.
I attached the make log.

Any help will be appreciated.

genbc's arguments should be

 ./genbc byte.def byte.c opt.c xlat.c

The segmentation fault is probably due to accessing a NULL pointer returned by fopen after a file not found error. (Not very robust, I must admit. But this program should only be run by maintainers and people who use git snapshots).

Indeed, in the make log there is no segmentation fault; this was fixed by http://git.savannah.gnu.org/gitweb/?p=smalltalk.git;a=commit;h=8b603c2

Please try the attached patch and send a new make log. Thanks!

You can find the new log attached.

Gdb output is the same:

gdb genbc.exe 
GNU gdb 6.8
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-pc-mingw32"...
(no debugging symbols found)
(gdb) set args byte.def byte.c opt.c xlat.c
(gdb) run
Starting program: d:\msys\1.0\home\stef\temp\smalltalk\libgst/genbc.exe byte.def byte.c opt.c xlat.c
[New thread 1548.0xbdc]
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)

Program exited with code 030000000005.

Hello,

After a long break I tried to compile GST's latest GIT version, again on Windows with autotools installed this time. I first got the problem Lee Duhem mentioned about SIZEOF_LONG. I applied the patch and changed "while (true)" to "for (;;)" like Paolo mentioned. Now I get the following error while compilation:

make  all-recursive
make[1]: Entering directory `/home/Canol/smalltalk-3.9.2009'
Making all in lib-src
make[2]: Entering directory `/home/Canol/smalltalk-3.9.2009/lib-src'
if /bin/sh ../libtool --mode=compile --tag=CC gcc -DHAVE_CONFIG_H -I. -I. -I..     -pipe -O2 -mms-bitfields -march=i686 -Wall -Wno-strict-aliasing -Wno-switch -fno-gcse -fstrict-aliasing -Wwrite-strings -Wdeclaration-after-statement -Wno-format -Wpointer-arith  -MT getaddrinfo.lo -MD -MP -MF ".deps/getaddrinfo.Tpo" -c -o getaddrinfo.lo getaddrinfo.c; \
        then mv -f ".deps/getaddrinfo.Tpo" ".deps/getaddrinfo.Plo"; else rm -f ".deps/getaddrinfo.Tpo"; exit 1; fi
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I. -I.. -pipe -O2 -mms-bitfields -march=i686 -Wall -Wno-strict-aliasing -Wno-switch -fno-gcse -fstrict-aliasing -Wwrite-strings -Wdeclaration-after-statement -Wno-format -Wpointer-arith -MT getaddrinfo.lo -MD -MP -MF .deps/getaddrinfo.Tpo -c getaddrinfo.c  -DDLL_EXPORT -DPIC -o .libs/getaddrinfo.o
getaddrinfo.c: In function `getnameinfo':
getaddrinfo.c:405: internal compiler error: in genrtl_break_stmt, at c-semantics.c:591
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://www.mingw.org/bugs.shtml> for instructions.
make[2]: *** [getaddrinfo.lo] Error 1
make[2]: Leaving directory `/home/Canol/smalltalk-3.9.2009/lib-src'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/Canol/smalltalk-3.9.2009'
make: *** [all] Error 2

I pushed the fix for pointer-set.c now.

I cannot do anything about internal compiler errors---moreover, mingw uses an extremely old compiler and there's no trace of genrtl_break_stmt in GCC 4.x.

Just trust me that I'll start distributing Windows binaries soon.