boehm-gc .comm problem

Tue Jun 5 15:15:00 GMT 2001

Many thanks to Robert and Tom for the helpful advice. The consensus
being that mingw32 is the better target to work with at the moment,
I am shifting my focus to that target.
My currently outstanding questions, or at least those with which some
readers might wish to help me resolve, are:
 1. Are there strong reasons to prefer working with win32 or posix
 threads, for a mingw32 target? If the latter, what is the best
 win32-pthreads distribution to work against?
 2. Is there a strong reason to prefer the trunk over the (more
 stable, or so I naively assume) 3.0 branch, for this purpose --
 i.e. producing native java executables for win32?
The rest of this message is to answer Robert's helpful questions.
Quoth Robert Collins on Tuesday, 5 June:
: I'd say that you need to build a mingw cross-compiler, not a cygwin
: cross compiler for starters.

Tom Tromey seemed to agree that Mingw would be a better approach,
so I'm going to go with this consensus advice and see what happens.
: The boehm-gc code seemed to work fine for me when I spent a few days
: getting libgcj going on cygwin. 

Right. Of course slight variations in the source base over time can
lead to substantial differences in behaviour, particularly for
marginal targets. Hans Boehm suggested that I should be using the
trunk, rather than 3.0 branch, as the gc pthreads support is improved.
This is a frightening prospect, considering the number of little hacks
and patches in my branch workspace.
: You can look in the java archives or the
: cygwin-apps archives 

I've been carefulling tracking the java@ list, but cygwin-apps is not
searchable, unfortunately. I did check the last three months for
tidbits, though, and saw the mid-April messages. Speaking of which, a
propos your thread on cygwin-apps, and in case you aren't already
aware of it, the -fbuiltin/-fno-builtin switch is documented to
control the availablility of the 'alloca' alias for __builtin_alloca.
: for the results from that. Another net contributor
: took what I'd done and finished it off - getting to the point of being
: able to run the tests. I'm not sure of the results of the test-runs, or
: the current status.

I think I have all of David Billinghurst's mods in my local tree.
: > cygwin/pthreads hosted on cygwin (which was hopelessly slow),
:: Where was it slow? What version of cygwin? (Pre-1.3.0 all thread-related
: calls where serialised). 

I am using the current version installed by setup.exe.
I suspect most of the time was consumed inside make.exe with shell
forks or something like that. It would take at least a day to do 
a build from scratch on cygwin, on my P3-700 laptop.
: > cygwin/pthreads on linux (run-time problems in GC due to
: > implementation-dependencies in the GC code), 
:: I don't see how that differs from cygwin/pthreads on cygwin, unless your
: cross-compiler was broken.

The difference is that I actually had the patience to go down this
path long enough to encounter a bug:-)