Re: Compiling gst with mingw32

> Message: 3
> Date: Wed, 26 Sep 2007 06:29:45 +0200
> From: Paolo Bonzini <bonzinignu.org>
> Subject: [Help-smalltalk] Re: Compiling gst with
mingw32
> To: help-smalltalkgnu.org
> Message-ID: <fdcn7n$uf5$1sea.gmane.org>
> Content-Type: text/plain; charset=ISO-8859-1;
format=flowed
>
> 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 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
help-smalltalkgnu.org

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
help-smalltalkgnu.org

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=rl.ac.ukgnu.org
[mailto:help-smalltalk-bounces+f.a.akeroyd=rl.ac.ukgnu.org]
On Behalf
Of Cesar Rabak
Sent: 27 September 2007 03:49
To: help-smalltalkgnu.org
Subject: [Help-smalltalk] Re: Compiling gst with mingw32

> Message: 3
> Date: Wed, 26 Sep 2007 06:29:45 +0200
> From: Paolo Bonzini <bonzinignu.org>
> Subject: [Help-smalltalk] Re: Compiling gst with
mingw32
> To: help-smalltalkgnu.org
> Message-ID: <fdcn7n$uf5$1sea.gmane.org>
> Content-Type: text/plain; charset=ISO-8859-1;
format=flowed
>
> 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 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
help-smalltalkgnu.org

http://lists.gnu.org/mailman/listinfo/help-smalltalk

_______________________________________________
help-smalltalk mailing list
help-smalltalkgnu.org

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
help-smalltalkgnu.org

http://lists.gnu.org/mailman/listinfo/help-smalltalk

2007/9/27, Akeroyd, FA (Freddie) <F.A.Akeroydrl.ac.uk>:
> 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
help-smalltalkgnu.org

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:csrabakibest.com.br] 
Sent: 28 September 2007 01:24
To: Akeroyd, FA (Freddie)
Cc: help-smalltalkgnu.org
Subject: Re: [Help-smalltalk] Re: Compiling gst with
mingw32

2007/9/27, Akeroyd, FA (Freddie) <F.A.Akeroydrl.ac.uk>:
> 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
help-smalltalkgnu.org

http://lists.gnu.org/mailman/listinfo/help-smalltalk

2007/9/28, Akeroyd, FA (Freddie) <F.A.Akeroydrl.ac.uk>:
> 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.

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
help-smalltalkgnu.org

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
help-smalltalkgnu.org

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.no
candysw.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
help-smalltalkgnu.org

http://lists.gnu.org/mailman/listinfo/help-smalltalk

2007/9/29, Stephen Compall <s11member.fsf.org>:
> 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
help-smalltalkgnu.org

http://lists.gnu.org/mailman/listinfo/help-smalltalk