Compiling gst with mingw32

After some years used to run GNU smalltalk in Linux boxes, I've come
to a job where workstations and the products are Microsoft Windows.

So I'm trying to produce an installable package for Windows.

My machine is a Windows XP SP2, and I'm using MSYS environment in
order to compile using mingw32 (which I think is more amenable for
users than having to install Cygwin libraries).

I unpacked, ran configure and fired make.

Make stops with:

gcc -DHAVE_CONFIG_H -I. -I. -I..
-DKERNEL_PATH=\"/usr/local/share/smalltalk/kernel\"
-DIMAGE_PATH=\"/usr/local/share/smalltalk\"
-DMODULE_PATH=\"/usr/local/lib/smalltalk\" -I../lib-src
-I../libffi/include -I../libffi/include -I../snprintfv -I../snprintfv
-I../lib-src -I../lightning -I../lightning -I.. -I.. -g -O2 -Wall
-fstrict-aliasing -fno-gcse -Wno-strict-aliasing -Wno-switch
-Wno-format -Wpointer-arith -Wwrite-strings -MT interp.lo -MD -MP -MF
.deps/interp.Tpo -c interp.c  -DDLL_EXPORT -DPIC -fomit-frame-pointer
-o .libs/interp.o
In file included from interp.c:715:
prims.def: In function `VMpr_FileDescriptor_fileOp':
prims.def :5209: warning: implicit declaration of function `mkstemp'
prims.def:5421: warning: implicit declaration of function `ftruncate'
prims.def:5483: error: `ENOTSOCK' undeclared (first use in this function)
prims.def:5483: error: (Each undeclared identifier is reported only once
prims.def:5483: error: for each function it appears in.)
interp.c: In function `interrupt_handler':
interp.c:2453: warning: implicit declaration of function `strsignal'
dict.inl: At top level:
interp.c:225: warning: alignment of `method_cache' is greater than
maximum object file alignment. Using 16
interp.c:252: warning: alignment of `queued_async_signals' is greater
than maximum object file alignment. Using 16
interp.c:687: warning: alignment of `chunks' is greater than maximum
object file alignment. Using 16
interp.c:696: warning: alignment of `lifo_contexts' is greater than
maximum object file alignment. Using 16
make[3]: *** [interp.lo] Error 1
make[3]: Leaving directory
`/e/Programacao/Linguagens/Smalltalk/GNU/smalltalk-2.3.6/libgst'
make[2]: *** [all] Error 2
make[2]: Leaving directory
`/e/Programacao/Linguagens/Smalltalk/GNU/smalltalk- 2.3.6/libgst'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory
`/e/Programacao/Linguagens/Smalltalk/GNU/smalltalk-2.3.6'
make: *** [all] Error 2

Compilation exited abnormally with code 2 at Mon Sep 24 11:36:36

Since config.log shows configure found correctly:

hostname = fuba
uname -m = i686
uname -r = 1.0.10(0.46/3/2)
uname -s = MINGW32_NT-5.1
uname -v = 2003-10-11 10:14

And at its  whereabouts of line 2900:

configure:16238: checking for strsignal
configure:16294: gcc -o conftest.exe -g -O2 -Wall -fstrict-aliasing
-fno-gcse -Wno-strict-aliasing -Wno-switch -Wno-format -Wpointer-arith
-Wwrite-strings    conftest.c -lm  >&5
C:/DOCUME~1/CESARS~1.RAB/CONFIG~1/Temp/ccsDaaaa.o(.text+0x16): In
function `main':
e:/Programacao/Linguagens/Smalltalk/GNU/smalltalk-2.3.6/conftest.c:89:
undefined reference to `strsignal'
configure:16300: $? = 1
configure: failed program was:
| /* confdefs.h.  */
| #define PACKAGE_NAME "GNU Smalltalk"
| #define PACKAGE_TARNAME "smalltalk"
| #define PACKAGE_VERSION "2.3.6"
| #define PACKAGE_STRING "GNU Smalltalk 2.3.6"
| #define PACKAGE_BUGREPORT "[hidden email]"
| #define ST_MAJOR_VERSION 2
| #define ST_MINOR_VERSION 3
| #define ST_EDIT_VERSION 6
| #define MAINTAINER " [hidden email]"
| #define PACKAGE "smalltalk"
| #define VERSION "2.3.6"
| #define STDC_HEADERS 1
| #define HAVE_SYS_TYPES_H 1
| #define HAVE_SYS_STAT_H 1
| #define HAVE_STDLIB_H 1
| #define HAVE_STRING_H 1
| #define HAVE_MEMORY_H 1
| #define HAVE_STRINGS_H 1
| #define HAVE_INTTYPES_H 1
| #define HAVE_STDINT_H 1
| #define HAVE_UNISTD_H 1
| #define restrict __restrict
| #define HAVE_GOTO_VOID_P 1
| #define HOST_SYSTEM "i686-pc-mingw32"
| #define ALIGNOF_DOUBLE 8
| #define ALIGNOF_LONG_DOUBLE 4
| #define SIZEOF_OFF_T 4
| #define SIZEOF_OOP 4
| #define RETSIGTYPE void
| #define _GNU_SOURCE 1
| #define HAVE_STDINT_H 1
| #define HAVE_INTTYPES_H 1
| #define HAVE_UNISTD_H 1
| #define HAVE_SYS_PARAM_H 1
| #define HAVE_STDDEF_H 1
| #define HAVE_LIMITS_H 1
| #define HAVE_SYS_TIMEB_H 1
| #define HAVE_SYS_FILE_H 1
| #define HAVE_UTIME_H 1
| #define HAVE_FCNTL_H 1
| #define HAVE_LONG_LONG_INT 1
| #define HAVE_INTMAX_T 1
| #define HAVE_INTPTR_T 1
| #define HAVE_UNSIGNED_LONG_LONG_INT 1
| #define HAVE_UINTMAX_T 1
| #define HAVE_UINTPTR_T 1
| #define HAVE_ALLOCA 1
| #define HAVE_LIBM 1
| #define poll rpl_poll
| #define HAVE_PUTENV 1
| #define HAVE_STRDUP 1
| #define HAVE_STRERROR 1
| /* end confdefs.h.  */
| /* Define strsignal to an innocuous variant, in case <limits.h>
declares strsignal.
|    For example, HP-UX 11i <limits.h> declares gettimeofday.  */
| #define strsignal innocuous_strsignal
|
| /* System header to define __stub macros and hopefully few prototypes,
|     which can conflict with char strsignal (); below.
|     Prefer <limits.h> to <assert.h> if __STDC__ is defined, since
|     <limits.h> exists even on freestanding compilers.  */
|
| #ifdef __STDC__
| # include <limits.h>
| #else
| # include <assert.h>
| #endif
|
| #undef strsignal
|
| /* Override any GCC internal prototype to avoid an error.
|    Use char because int might match the return type of a GCC
|    builtin and then its argument prototype would still apply.  */
| #ifdef __cplusplus
| extern "C"
| #endif
| char strsignal ();
| /* The GNU C library defines this for functions which it implements
|     to always fail with ENOSYS.  Some functions are actually named
|     something starting with __ and the normal name is an alias.  */
| #if defined __stub_strsignal || defined __stub___strsignal
| choke me
| #endif
|
| int
| main ()
| {
| return strsignal ();
|   ;
|   return 0;
| }
configure:16318: result: no

I would surmise that configure machinery would find a way around (in
fact it would have to find ways around mkstemp, ftruncate, strsep,
etc.), or no?

TIA

--
Cesar Rabak


_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

On Tue, 2007-09-25 at 14:17 -0300, Cesar Rabak wrote:
> My machine is a Windows XP SP2, and I'm using MSYS environment in
> order to compile using mingw32 (which I think is more amenable for
> users than having to install Cygwin libraries).

Please see http://smalltalk.gnu.org/faq/45 , also
http://www.gnu.org/prep/standards/html_node/System-Portability.html .

> I would surmise that configure machinery would find a way around (in
> fact it would have to find ways around mkstemp, ftruncate, strsep,
> etc.), or no?

For some of these functions, gnulib would help.

--
;;; Stephen Compall ** http://scompall.nocandysw.com/blog **
"Peta" is Greek for fifth; a petabyte is 10 to the fifth power, as
well as fifth in line after kilo, mega, giga, and tera.
  -- Lee Gomes, performing every Wednesday in his tech column
     "Portals" on page B1 of The Wall Street Journal

_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

Cesar Rabak wrote:
> After some years used to run GNU smalltalk in Linux boxes, I've come
> to a job where workstations and the products are Microsoft Windows.
>
> So I'm trying to produce an installable package for Windows.

2.3.6 should work; 2.95d will before becoming 3.0 but not yet, as you
found out.

> I would surmise that configure machinery would find a way around (in
> fact it would have to find ways around mkstemp, ftruncate, strsep,
> etc.), or no?

Yes, in lib-src there are ports for many of these functions.

Paolo



_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

I downloaded 2.3.6 extracted and fired configure.

Same results...

> > I would surmise that configure machinery would find a way around (in
> > fact it would have to find ways around mkstemp, ftruncate, strsep,
> > etc.), or no?
>
> Yes, in lib-src there are ports for many of these functions.

This is the mystery: up to the error in compiling interp.c, the
lib-src already have the port of functions compiled!

The issue appears to be that no header file is generated by configure
to have prototypes for those functions.

So when prims.def is included, gcc barfs at "implicit declaration of
function ..." and non existent macros like "ENOTSOCK" generate errors
stopping the build process.

Regards,

--
Cesar Rabak


_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

> Same results...

You can comment out the "if" involving ENOTSOCK (both versions).

> So when prims.def is included, gcc barfs at "implicit declaration of
> function ..." and non existent macros like "ENOTSOCK" generate errors
> stopping the build process.

Implicit declarations should not be a problem, and references to
non-existent macros are portability problems that have not been
accounted for.

Paolo


_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

Hi,

If you unpack a clean 2.3.6 distribution, cd into the top directory and
apply the enclosed patch via

patch -p0 < mingw.patch
touch aclocal.m4 config.h.in configure

It should fix the problems. You may get a warning about automake-1.9 not
being available when you "configure and make", but you can ignore that.

Regards,

Freddie

-----Original Message-----
From: help-smalltalk-bounces+f.a.akeroyd=[hidden email]
[mailto:help-smalltalk-bounces+f.a.akeroyd=[hidden email]] On Behalf
Of Cesar Rabak
Sent: 27 September 2007 03:49
To: [hidden email]
Subject: [Help-smalltalk] Re: Compiling gst with mingw32

Same results...

> > I would surmise that configure machinery would find a way around (in
> > fact it would have to find ways around mkstemp, ftruncate, strsep,
> > etc.), or no?
>
> Yes, in lib-src there are ports for many of these functions.

This is the mystery: up to the error in compiling interp.c, the
lib-src already have the port of functions compiled!

The issue appears to be that no header file is generated by configure
to have prototypes for those functions.

So when prims.def is included, gcc barfs at "implicit declaration of
function ..." and non existent macros like "ENOTSOCK" generate errors
stopping the build process.

Regards,

--
Cesar Rabak


_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

Akeroyd, FA (Freddie) wrote:
> Hi,
>
> If you unpack a clean 2.3.6 distribution, cd into the top directory and
> apply the enclosed patch via
>
> patch -p0 < mingw.patch
> touch aclocal.m4 config.h.in configure

Thanks, Freddie.  Will apply soon.

Paolo


_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

2007/9/27, Akeroyd, FA (Freddie) <[hidden email]>: Hi Freddie,

Your patch fixed the problems and gave the warnings as you predicted!

I had a small stumble on the building of docs (help2man has the path
for perl hardcoded and in a mingw32 installation it is available in
the binary path).

However, even if after I tried calling manually doing 'perl
../build-aux/help2man... etc., it failed saying help2man could not get
--help from gst.

After that, make complained I have not autom4te (which is true, but
configure did not complain earlier).

I was able to run make check and now I installed it with make install.

Present status: command line gst seems to be working (will test more
thoroughly tomorrow) but even though I compiled using:
./configure --with-tcl=/mingw/lib/ --with-tk=/mingw/lib

And I have a tcl and a tk in my mingw32 installation, as well as the
tclConfig.sh and tkConfig.sh there, I could not run Blox.

Regards,

--
Cesar Rabak


_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

Hi,

I hadn't tried using Blox before but if you edit blox-tk/BloxTK.c and
change calls to index() to strchr() and then run configure as

env LIBS="-ltk84 -ltcl84" ./configure --with-tcl=/mingw/lib

It seems to compile and link; i'm not sure why the default tcl libraries
are not picked up though

Once built you will need to copy   blox-tk/.libs/blox-tk-2-3-6.dll   to
 blox-tk.dll in the appropriate location; however when I run      

./gst browser/Run.st

I don't get a window, so further investigation is needed.

With regard to "help2man" I can run

make gst.1

OK from the doc directory, so I'm not sure what the cause of the problem
is there

Regards,

Freddie

-----Original Message-----
From: Cesar Rabak [mailto:[hidden email]]
Sent: 28 September 2007 01:24
To: Akeroyd, FA (Freddie)
Cc: [hidden email]
Subject: Re: [Help-smalltalk] Re: Compiling gst with mingw32

2007/9/27, Akeroyd, FA (Freddie) <[hidden email]>:
> Hi,
>
> If you unpack a clean 2.3.6 distribution, cd into the top directory
and
> apply the enclosed patch via
>
> patch -p0 < mingw.patch
> touch aclocal.m4 config.h.in configure
>
> It should fix the problems. You may get a warning about automake-1.9
not
> being available when you "configure and make", but you can ignore
that.
>
Hi Freddie,

Your patch fixed the problems and gave the warnings as you predicted!

I had a small stumble on the building of docs (help2man has the path
for perl hardcoded and in a mingw32 installation it is available in
the binary path).

However, even if after I tried calling manually doing 'perl
../build-aux/help2man... etc., it failed saying help2man could not get
--help from gst.

After that, make complained I have not autom4te (which is true, but
configure did not complain earlier).

I was able to run make check and now I installed it with make install.

Present status: command line gst seems to be working (will test more
thoroughly tomorrow) but even though I compiled using:
./configure --with-tcl=/mingw/lib/ --with-tk=/mingw/lib

And I have a tcl and a tk in my mingw32 installation, as well as the
tclConfig.sh and tkConfig.sh there, I could not run Blox.

Regards,

--
Cesar Rabak


_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

Akeroyd, FA (Freddie) wrote:
> Hi,
>
> I hadn't tried using Blox before but if you edit blox-tk/BloxTK.c and
> change calls to index() to strchr() and then run configure as
>
> env LIBS="-ltk84 -ltcl84" ./configure --with-tcl=/mingw/lib

> It seems to compile and link; i'm not sure why the default tcl libraries
> are not picked up though

Can (any of) you send me your tclConfig.sh file?  Thanks.

Paolo


_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

2007/9/28, Akeroyd, FA (Freddie) <[hidden email]>:
I'll try and see how far I get.

>
> With regard to "help2man" I can run
>
> make gst.1
>
> OK from the doc directory, so I'm not sure what the cause of the problem
> is there

Let me see if I can get further data, and will report back.


_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

Another issue appeared in my build in mingw32:

Having it installed in the machine's path (in fact I have a specific
cmd [a.k.a 'batch"] file that starts a command prompt with all
variables set); if I fire gst.exe I get the toplevel (gst shell) with
the familiar "st> " prompt.

However, after I interact with it a little if I put the focus in any
other Windows application, gst returns to the operating system or
saying in other terms: the commad prompt turns back to CMD (e.g.
C:\>).

Do you have seen anything similar to this? I'm not sure nor from where
start to debug this!

Regards,

--
Cesar Rabak


_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

On Sat, 2007-09-29 at 16:23 -0300, Cesar Rabak wrote:
> However, after I interact with it a little if I put the focus in any
> other Windows application, gst returns to the operating system or
> saying in other terms: the commad prompt turns back to CMD (e.g.
> C:\>).
>
> Do you have seen anything similar to this? I'm not sure nor from where
> start to debug this!

Yes, Windows halts (but does not kill) all processes run under a command
prompt when they are out of focus.  Oddly, this doesn't apply to Cygwin,
which seems to handle it correctly somehow.  The place to start would be
to figure out what Windows does to stop cmd processes in this case and
fix the VM to ignore the signal (or something) on Windows.  But first I
would check the Cygwin version to make sure it doesn't happen there on
your system.

I learned about that the hard way when trying to run a long installation
process in a background cmd window. :)

--
;;; Stephen Compall ** http://scompall.nocandysw.com/blog **
"Peta" is Greek for fifth; a petabyte is 10 to the fifth power, as
well as fifth in line after kilo, mega, giga, and tera.
  -- Lee Gomes, performing every Wednesday in his tech column
     "Portals" on page B1 of The Wall Street Journal

_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

2007/9/29, Stephen Compall <[hidden email]>:
I'll need to wait if some other person reading this list has built a
Cygwin version and has the same behaviour.

>
> I learned about that the hard way when trying to run a long installation
> process in a background cmd window. :)

I'm starting to understand why a lot of programs ported to Windows
have their own "shell" while in Linux they just have a toplevel in
command line...

gst seems to be usable for running scripts and even works integrated
with Emacs in Windows.

Thanks,

--
Cesar Rabak


_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

Hi,

I think the problem is that the change of window generates a focus
change console event; this counts as "input available" and so wakes up
the process, but as there are actually no characters to read win_recv()
in
lib-src/socketx.c returns 0 which is converted into a POLLHUP by
lib-src/poll.c

A nasty workaround is to edit lib-src/socketx.c and change the final
line of win_recv() to

return (nread == 0 ? 1 : nread);

This will cause the calling read() operation to block for input, which
will be OK so long as the process is not waiting on multiple input
sources.

I'll have a think about a better fix

Regards,

Freddie

-----Original Message-----
From: help-smalltalk-bounces+f.a.akeroyd=[hidden email]
[mailto:help-smalltalk-bounces+f.a.akeroyd=[hidden email]] On Behalf
Of Cesar Rabak
Sent: 30 September 2007 06:10
To: [hidden email]
Subject: [Help-smalltalk] Re: Compiling gst with mingw32

2007/9/29, Stephen Compall <[hidden email]>:
> On Sat, 2007-09-29 at 16:23 -0300, Cesar Rabak wrote:
> > However, after I interact with it a little if I put the focus in any
> > other Windows application, gst returns to the operating system or
> > saying in other terms: the commad prompt turns back to CMD (e.g.
> > C:\>).
> >
> > Do you have seen anything similar to this? I'm not sure nor from
where
> > start to debug this!
>
> Yes, Windows halts (but does not kill) all processes run under a
command
> prompt when they are out of focus.  Oddly, this doesn't apply to
Cygwin,
> which seems to handle it correctly somehow.  The place to start would
be
> to figure out what Windows does to stop cmd processes in this case and
> fix the VM to ignore the signal (or something) on Windows.  But first
I
> would check the Cygwin version to make sure it doesn't happen there on
> your system.

I'll need to wait if some other person reading this list has built a
Cygwin version and has the same behaviour.

>
> I learned about that the hard way when trying to run a long
installation
> process in a background cmd window. :)

I'm starting to understand why a lot of programs ported to Windows
have their own "shell" while in Linux they just have a toplevel in
command line...

gst seems to be usable for running scripts and even works integrated
with Emacs in Windows.

Thanks,

--
Cesar Rabak


_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk


_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

Akeroyd, FA (Freddie) wrote:
I think it's possible to call PeekConsoleInput in win_select, in this
final loop:

   /* now do a quick poll of all handles to see how many are ready */

Paolo


_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

2007/10/1, Akeroyd, FA (Freddie) <[hidden email]>: Hi  Freddie,

Just to be useful, are thinking of testing this or are you also
without access to a Windows machine and would profit if I try this?

Regards,

--
Cesar Rabak


_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

> Hi  Freddie,
>
> Just to be useful, are thinking of testing this or are you also
> without access to a Windows machine and would profit if I try this?

He has one, indeed he is the one who has done most of the work on the
native port.

Paolo


_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

Cesar Rabak wrote:
The tclConfig.sh file does not mention them. :-(  It can be fixed
properly, for now, can you try this workaround?  (This patch should be
applied to the configure script).

--- configure        2007-09-27 16:03:05.000000000 +0200
+++ configure   2007-10-02 10:30:43.000000000 +0200
@@ -20676,8 +20676,14 @@

    if test "$gst_cv_tcltk_includes" != "not found"; then
      # The indirection is required by Tcl/Tk
-    gst_cv_tcltk_libs="$TCL_LIBS $TK_XLIBSW $TCL_LIB_SPEC $TK_LIB_SPEC"
-    gst_cv_tcltk_libs=`eval echo $gst_cv_tcltk_libs`
+    if test "x$TCL_LIB_SPEC" = x; then
+      gst_cv_tcltk_libs="$TCL_LIBS $TK_XLIBSW $TCL_STUB_LIB_SPEC
$TK_STUB_LIB_SPEC"
+      gst_cv_tcltk_libs=`eval echo $gst_cv_tcltk_libs`
+      gst_cv_tcltk_libs=`echo $gst_cv_tcltk_libs | sed 's,stub,,g'`
+    else
+      gst_cv_tcltk_libs="$TCL_LIBS $TK_XLIBSW $TCL_LIB_SPEC $TK_LIB_SPEC"
+      gst_cv_tcltk_libs=`eval echo $gst_cv_tcltk_libs`
+    fi

      CPPFLAGS="$save_cppflags $gst_cv_tcltk_includes"
      LIBS="$save_libs $gst_cv_tcltk_libs"



_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk