Windows build

Hi,

I tried building with cygwin myself and get a similar problem with
default C compiler optimisation:

Latest git

    ./configure --disable-generational-gc
    make

stopped at

    ./gst.exe --no-user-files --kernel-dir="./kernel" --image=gst.im -iQ
/dev/null
          7 [main] gst 3604 _cygtls::handle_exceptions: Error while
dumping state (probably corrupted stack)
    make[2]: *** [gst.im] Segmentation fault (core dumped)

$ gdb ./gst.exe
GNU gdb 6.8.0.20080328-cvs (cygwin-special) Copyright (C) 2008 Free
Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
<http://gnu.org/licenses/gpl.html>
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-cygwin"...
(no debugging symbols found)
No symbol table is loaded.  Use the "file" command.
Make breakpoint pending on future shared library load? (y or [n])
[answered N; input not from terminal]
(gdb) r --no-user-files --kernel-dir="./kernel" --image=gst.im -iQ
/dev/null Starting program: /cygdrive/c/cygwin_local/smalltalk/gst.exe
--no-user-files --kernel-dir="./kernel" --image=gst.im -iQ /dev/null
[New thread 2672.0xb64] (no debugging symbols found)  (no debugging
symbols found) (no debugging symbols found) [New thread 2672.0xa48] (no
debugging symbols found)  (no debugging symbols found) [New thread
2672.0x1e4]
      7 [main] gst 2672 _cygtls::handle_exceptions: Exception:
STATUS_ACCESS_VIOLATION
   2634 [main] gst 2672 open_stackdumpfile: Dumping stack trace to
gst.exe.stack dump
   9722 [main] gst 2672 _cygtls::handle_exceptions: Exception:
STATUS_ACCESS_VIOLATION
  12405 [main] gst 2672 _cygtls::handle_exceptions: Error while dumping
state (probably corrupted stack)

Program exited with code 0105400.
(gdb)


However rebuilding without C compiler optimisation

    env CFLAGS="-g -O0" ./configure --disable-generational-gc
    make

runs through OK and builds both gst.exe and a gst.im image; however
running the tests results in a hang loading SUnit

make check
Making check in tests
make[1]: Entering directory `/cygdrive/c/cygwin_local/smalltalk/tests'
make  gst.im
make[2]: Entering directory `/cygdrive/c/cygwin_local/smalltalk/tests'
echo "PackageLoader fileInPackage: #SUnit. ObjectMemory snapshot:
'gst.im'" | ./gst --image=../gst.im - "Global garbage collection...
done"
Loading package SUnit
"Global garbage collection... done"
cd . && /cygdrive/c/cygwin_local/smalltalk/tests/gst -S
--image=/cygdrive/c/cygwin_local/smalltalk/tests/gst.im AnsiLoad.st
Object: StarPackage new "<0x18f9fe68>" error: did not understand
#isDisabled MessageNotUnderstood(Exception)>>signal (AnsiExcept.st:216)
Kernel.StarPackage(Object)>>doesNotUnderstand: #isDisabled
(AnsiLoad.st:65) optimized [] in
Kernel.PackageDirectory>>refreshPackageList (PkgLoader.st:436) [] in
LookupTable(Dictionary)>>reject: (Dictionary.st:400) [] in
LookupTable>>associationsDo: (LookupTable.st:149)
LookupTable>>keysAndValuesDo: (LookupTable.st:179)
LookupTable>>associationsDo: (LookupTable.st:148)
LookupTable(Dictionary)>>reject: (Dictionary.st:401)
Kernel.PackageDirectory>>refreshPackageList (PkgLoader.st:436)
Kernel.PackageDirectory>>refresh: (PkgLoader.st:424) [] in
Kernel.PackageDirectories>>refresh: (PkgLoader.st:254)
OrderedCollection(SequenceableCollection)>>do: (SeqCollect.st:822)
Kernel.PackageDirectories>>refresh: (PkgLoader.st:254)
PackageLoader"Global garbage collection... done"
 class>>refresh (PkgLoader.st:1693)
PackageLoader class>>fileInPackages: (PkgLoader.st:1710) PackageLoader
class>>fileInPackage: (PkgLoader.st:1700)
UndefinedObject>>executeStatements (AnsiLoad.st:79)
Loading Ansi.st
Loading AnsiDB.st
"Global garbage collection... done, heap grown"
Loading AnsiInit.st
"Global garbage collection... done"
"Global garbage collection... done"
make[2]: Leaving directory `/cygdrive/c/cygwin_local/smalltalk/tests'
make  check-local
make[2]: Entering directory `/cygdrive/c/cygwin_local/smalltalk/tests'
/bin/sh './testsuite'
## ----------------------------- ##
## GNU Smalltalk 3.1 test suite. ##
## ----------------------------- ##

Regression tests.

  1: arrays.st                                       ok
  2: classes.st                                      ok
  3: blocks.st                                       ok
  4: sets.st                                         ok
  5: exceptions.st                                   ok
  6: intmath.st                                      ok
  7: floatmath.st                                    ok
  8: dates.st                                        ok
  9: objects.st                                      ok
 10: strings.st                                      ok
 11: chars.st                                        ok
 12: objdump.st                                      ok
 13: geometry.st                                     ok
 14: cobjects.st                                     ok
 15: compiler.st                                     ok
 16: fileext.st                                      ok
 17: mutate.st                                       ok
 18: untrusted.st                                    ok
 19: getopt.st                                       ok
 20: quit.st                                         ok
 21: pools.st                                        ok

Other simple tests.

 22: ackermann.st                                    ok
 23: ary3.st                                         ok
 24: except.st                                       ok
 25: fibo.st                                         ok
 26: hash.st                                         ok
 27: hash2.st                                        ok
 28: heapsort.st                                     ok
 29: lists.st                                        ok
 30: lists1.st                                       ok
 31: lists2.st                                       ok
 32: matrix.st                                       ok
 33: methcall.st                                     ok
 34: nestedloop.st                                   ok
 35: objinst.st                                      ok
 36: prodcons.st                                     ok
 37: random-bench.st                                 ok
 38: sieve.st                                        ok
 39: strcat.st                                       ok

Basic packages.

 40: SUnit


Pressing "ctrl-c" at this point results in an "ok" for SUnit and then
the others tests continue with a few failures and further hangs at
Magritte, Sport and Swazoo which are also bypassed by pressing Ctrl-C. I
enclose the final "testsuite.log" file

Regards,

Freddie
and --
Scanned by iCritical.


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

On 12/09/2009 06:55 PM, [hidden email] wrote:
> Hi,
>
> I tried building with cygwin myself and get a similar problem with
> default C compiler optimisation:

Hmm, what version of Cygwin?

Paolo



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

Hi,

I updated cygwin from the web just prior to the build, so it should be
the latest packages from the Cygwin 1.5.25 DLL series. I was using the
default gcc 3.4.4 - are you using this or gcc4 ?

I also have both MinGW and Visual Studio installed on the computer -
might they be causing problems? I've just tried a rebuild with
optimisation after unsetting LIBRARY_PATH, LIB and INCLUDE from within
cygwin and also removing all non-cygwin directories from the end of
PATH, but it failed to generate gst.im in the same way as before.

Regards,

Freddie

--
Scanned by iCritical.


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

On Thu, Dec 10, 2009 at 11:20,  <[hidden email]> wrote:
> Hi,
>
> I updated cygwin from the web just prior to the build, so it should be
> the latest packages from the Cygwin 1.5.25 DLL series. I was using the
> default gcc 3.4.4 - are you using this or gcc4 ?

Great troubleshooting!

pbonzini@yakj ~
$ uname -a
CYGWIN_NT-5.2-WOW64 yakj 1.5.25(0.156/4/2) 2008-06-12 19:34 i686 Cygwin

pbonzini@yakj ~
$ gcc --version
gcc (GCC) 4.3.2 20080827 (beta) 2
Copyright (C) 2008 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Ang, I suggest that you upgrade to GCC 4.x, it should solve your woes.  Sorry!

Paolo


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

Hi Paolo,

Yes, that sorts out the build with optimisation problem - using

    env CC=gcc-4 ./configure --without-readline
--disable-generational-gc

generated gst.exe and gst.im OK, but when I ran "make check" I had
similar issues to the non-optimised gcc-3 build
 
Making check in tests
make[1]: Entering directory `/cygdrive/c/cygwin_local/smalltalk/tests'
make  gst.im
make[2]: Entering directory `/cygdrive/c/cygwin_local/smalltalk/tests'
echo "PackageLoader fileInPackage: #SUnit. ObjectMemory snapshot:
'gst.im'" | ./
gst --image=../gst.im -
"Global garbage collection... done"
Loading package SUnit
"Global garbage collection... done"
cd . && /cygdrive/c/cygwin_local/smalltalk/tests/gst -S
--image=/cygdrive/c/cygw
in_local/smalltalk/tests/gst.im AnsiLoad.st
Object: StarPackage new "<0x18a74fa0>" error: did not understand
#isDisabled
MessageNotUnderstood(Exception)>>signal (AnsiExcept.st:216)
Kernel.StarPackage(Object)>>doesNotUnderstand: #isDisabled
(AnsiLoad.st:65)
optimized [] in Kernel.PackageDirectory>>refreshPackageList
(PkgLoader.st:436)
[] in LookupTable(Dictionary)>>reject: (Dictionary.st:400)
[] in LookupTable>>associationsDo: (LookupTable.st:149)
LookupTable>>keysAndValuesDo: (LookupTable.st:179)
LookupTable>>associationsDo: (LookupTable.st:148)
LookupTable(Dictionary)>>reject: (Dictionary.st:401)
Kernel.PackageDirectory>>refreshPackageList (PkgLoader.st:436)
Kernel.PackageDirectory>>refresh: (PkgLoader.st:424)
[] in Kernel.PackageDirectories>>refresh: (PkgLoader.st:254)
OrderedCollection(SequenceableCollection)>>do: (SeqCollect.st:822)
Kernel.PackageDirectories>>refresh: (PkgLoader.st:254)
PackageLoader"Global garbage collection... done"
 class>>refresh (PkgLoader.st:1693)
PackageLoader class>>fileInPackages: (PkgLoader.st:1710)
PackageLoader class>>fileInPackage: (PkgLoader.st:1700)
UndefinedObject>>executeStatements (AnsiLoad.st:79)
Loading Ansi.st
Loading AnsiDB.st
"Global garbage collection... done, heap grown"
Loading AnsiInit.st
"Global garbage collection... done"
"Global garbage collection... done"
make[2]: Leaving directory `/cygdrive/c/cygwin_local/smalltalk/tests'
make  check-local
make[2]: Entering directory `/cygdrive/c/cygwin_local/smalltalk/tests'
/bin/sh './testsuite'
## ----------------------------- ##
## GNU Smalltalk 3.1 test suite. ##
## ----------------------------- ##

Regression tests.

  1: arrays.st                                       ok
  2: classes.st                                      ok
  3: blocks.st                                       ok

The tests then continue OK until they hang at "SUnit", "Magritte",
"Sport" and "Swazoo" - pressing Ctrl-C to abort the individual test
allows things to continue. I enclose the final testsuite.log file which
contains "Invalid C call-out MD5AllocOOP" and "Invalid C call-out
SHA1AllocOOP" messages; would these be the cause of the test hangs?  

Regards,

Freddie
is
> NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
> PURPOSE.
>
> Ang, I suggest that you upgrade to GCC 4.x, it should solve your woes.
> Sorry!
>
> Paolo

--
Scanned by iCritical.


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

On 12/10/2009 08:19 PM, [hidden email] wrote:
> Hi Paolo,
>
> Yes, that sorts out the build with optimisation problem - using
>
>      env CC=gcc-4 ./configure --without-readline
> --disable-generational-gc
>
> generated gst.exe and gst.im OK, but when I ran "make check" I had
> similar issues to the non-optimised gcc-3 build

I'll look into it.

Paolo


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

Hi all.

Sorry, I'm quite new to all of this, therefore I don't quite follow discussion between Freddie and Paolo.
I have gcc4.3.2, along with others in cygwin devel package. Is it you guys suggest me to build without C optimisation? If so, how exactly I should do to achieve that?

Thanks.

Ang Beepeng

Paolo Bonzini-2 wrote

On 12/10/2009 08:19 PM, freddie.akeroyd@stfc.ac.uk wrote:
> Hi Paolo,
>
> Yes, that sorts out the build with optimisation problem - using
>
>      env CC=gcc-4 ./configure --without-readline
> --disable-generational-gc
>
> generated gst.exe and gst.im OK, but when I ran "make check" I had
> similar issues to the non-optimised gcc-3 build

I'll look into it.

Paolo


_______________________________________________
help-smalltalk mailing list
help-smalltalk@gnu.org
http://lists.gnu.org/mailman/listinfo/help-smalltalk

Ang,

You can build with optimisation using gcc4, but it appears that
optimisation does not work with gcc3. I would suggest you use gcc4, but
on my cygwin installation the "gcc" command runs gcc 3.4.4 and gcc 4.3.2
is installed as a separate "gcc-4" command. This means you have to
invoke configure in a slightly different way

    env CC=gcc-4 ./configure --disable-generational-gc

Rather than

    ./configure --disable-generational-gc

This generates all the Makefiles etc. with "gcc-4" instead of "gcc" as
the C compiler; after this you can run "make" in the usual way.

Regards,

Freddie

>
> Hi all.
>
> Sorry, I'm quite new to all of this, therefore I don't quite follow
> discussion between Freddie and Paolo.
> I have gcc4.3.2, along with others in cygwin devel package. Is it you
> guys
> suggest me to build without C optimisation? If so, how exactly I
should
> do
> to achieve that?
>
> Thanks.
>
> Ang Beepeng
>

--
Scanned by iCritical.


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

Hi,

I do as advise. I still get errors. Hope that you guys can help.
http://askoh.net/mmu/beepeng/Smalltalk/GNU/video/20091212/gst20091212.html

Thanks.

Ang Beepeng

On 12/12/2009 07:50 AM, Ang Beepeng wrote:
>
> Hi,
>
> I do as advise. I still get errors. Hope that you guys can help.
> http://askoh.net/mmu/beepeng/Smalltalk/GNU/video/20091212/gst20091212.html

Can you give the output of "libtool --version"?

Paolo


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

Hi.

I got

$ libtool --version
libtool (GNU libtool 1.3110 2009-07-01) 2.2.7a
Written by Gordon Matzigkeit <gord@gnu.ai.mit.edu>, 1996

Thanks.

Ang Beepeng

Paolo Bonzini-2 wrote

Can you give the output of "libtool --version"?

Paolo

Hi,

If you type

    autoreconf --force -v -i

from your   c:/smalltalk/gnu/smalltalk3.1   directory and then try
"make" again does that help?

Freddie

>
> Hi,
>
> I do as advise. I still get errors. Hope that you guys can help.
>
http://askoh.net/mmu/beepeng/Smalltalk/GNU/video/20091212/gst20091212.ht
ml
>
> Thanks.
>
> Ang Beepeng
>

--
Scanned by iCritical.


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

On 12/13/2009 01:30 PM, [hidden email] wrote:
> Hi,
>
> If you type
>
>      autoreconf --force -v -i
>
> from your   c:/smalltalk/gnu/smalltalk3.1   directory and then try
> "make" again does that help?

I think she's done that many times already. :-(

Paolo


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

Ah, I wasn't sure if she had tried the "--force" option before - it
looks like "global_symbol_pipe" is not being set in "libtool" for some
reason and I though this might regenerate "libtool".

Freddie

>
> I think she's done that many times already. :-(
>
> Paolo
>

--
Scanned by iCritical.


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

On 12/13/2009 05:18 PM, [hidden email] wrote:
> Ah, I wasn't sure if she had tried the "--force" option before - it
> looks like "global_symbol_pipe" is not being set in "libtool" for some
> reason and I though this might regenerate "libtool".

Yeah, it can't do damage. :-)

Paolo


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

Hi,

Still not working. I saw this

*** Warning: linker path does not have real file for library -liconv.
*** I have the capability to make that library automatically link in when
*** you link to this library.  But I can only do this if you have a
*** shared version of the library, which you do not appear to have
*** because I did check the linker path looking for a file starting
*** with libiconv but no candidates were found. (...for file magic test)

*** Warning: libtool could not satisfy all declared inter-library
*** dependencies of module iconv.  Therefore, libtool will create
*** a static module, that should work as long as the dlopening
*** application is linked with the -dlopen flag.

*** However, this would only work if libtool was able to extract symbol
*** lists from a program, using `nm' or equivalent, but libtool could
*** not find such a program.  So, this module is probably useless.
*** `nm' from GNU binutils and a full rebuild may help.

Does it help?

I did these:

autoreconf --force -v -i
env CC=gcc-4 ./configure --disable-generational-gc
make
http://askoh.net/mmu/beepeng/Smalltalk/GNU/video/20091214/gst20091214.html

Can you share me your successful build of gst? Are they with debugging symbol?

Thanks.

Ang Beepeng

freddie.akeroyd wrote

Hi,

If you type

    autoreconf --force -v -i

from your   c:/smalltalk/gnu/smalltalk3.1   directory and then try
"make" again does that help?

On 12/14/2009 08:03 AM, Ang Beepeng wrote:
> Does it help?

Unfortunately that's kind of expected.  It just means that it couldn't
find some DLL.

> Can you share me your successful build of gst? Are they with debugging
> symbol?

I'll do so later today.

Paolo


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

just a suggestion, but do we need to build smalltalk locally on windows?

see, the other options is that someone offers their pre-compiled
binaries for windows on some public site

t

On Mon, Dec 14, 2009 at 2:31 AM, Paolo Bonzini <[hidden email]> wrote:


--
there are those who call me... (dr) timm (menzies)?
morgantown (39.6n, -79w), usa
assoc prof csee, wvu
http://menzies.us

PROBLEM: Handling e-mail is very very very slow, resulting in inbox overflow.
SOLUTION: Adopt the  "http://five.sentenc.es" policy: no responses
longer than 5 sentences. It’s that simple. Care to try it?


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

On 12/14/2009 02:35 PM, Tim Menzies wrote:
> see, the other options is that someone offers their pre-compiled
> binaries for windows on some public site

See, I've been planning to do this for a while and hope to get to it
during the holidays finally.  But Ang needs to develop, so she cannot
rely on binaries.

Since this is a volunteer project, I'm totally fed up of reading things
such as:

- "a user is trying to build on Windows and you just ask why don't you
try on Linux" after 20 messages in which I and Freddie tried to help Ang.

- "someone offers their pre-compiled binaries for Windows" after this
plan has been mentioned 200 times.  _Someone_ has a day-job too.

If something has been mentioned 200 times, the only reason why it's
worthwhile to say it the 201st, is if you decide to be the "someone".

If you think I suck as a maintainer because I don't provide Windows
binaries, fine with me, but then call things with their name please.

Paolo


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

On Mon, Dec 14, 2009 at 8:46 AM, Paolo Bonzini <[hidden email]> wrote:
dear paolo,

please allow me to publicly  express my enthusiasm for the gnu
smalltalk project and your tremendous work on that project.

i love scripting and text-based gnu smalltalk is right now my tool of
choice.  gnu smalltalk has brought me back to this wonderful language
after years of trying other things. i used to make $$$$ in the early
1990s selling smalltalk programming and mentor facilities but i was
always sad about the needless elaboration of a simple idea (smalltalk)
into overly-complex environments (visualworks, squeak, etc etc).

FYI: i ran two university subjects this year using gnu smalltalk and
what  was amazing is how LITTLE tutorial help i had to give students.
after 1-2 weeks mentoring, people stopped asking me about ST and
instead were asking me about the data used in the assignments. ST is a
perfect teaching tool: uniform, simple to learn.

you have enabled all the above. thank you.

t

p.s. regarding my suggestion to release pre-compiled windows binaries.
i did not know it was an FAQ and if i did i would not have suggested
it.

--
there are those who call me... (dr) timm (menzies)?
morgantown (39.6n, -79w), usa
assoc prof csee, wvu
http://menzies.us

PROBLEM: Handling e-mail is very very very slow, resulting in inbox overflow.
SOLUTION: Adopt the  "http://five.sentenc.es" policy: no responses
longer than 5 sentences. It’s that simple. Care to try it?


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