RE: boehm-gc .comm problem

["Robert Collins" <robert dot collins at itdomain dot com dot au>]

> -----Original Message-----
> From: Tony Kimball [mailto:alk@pobox.com]
> Sent: Tuesday, June 05, 2001 3:37 PM
> To: Robert Collins
> Cc: java@gcc.gnu.org; cygwin@cygwin.com
> Subject: RE: boehm-gc .comm problem
> 
> 
> Quoth Robert Collins on Tuesday, 5 June:
> : Might I suggest using pthreads? They are the official threads for
> : cygwin.
> 
> I tried that, but the Boehm GC code depends on implementation details
> of Linux threads, and did not trivially port to cygwin.  I'm planning
> to compile -mno-cygwin anyhow, so pthreads are not really an option
> unless i am willing to add a dependency on the stand-alone pthreads
> lib from win32, which I'd rather not do, all other things being equal.

I'd say that you need to build a mingw cross-compiler, not a cygwin
cross compiler for starters.

The boehm-gc code seemed to work fine for me when I spent a few days
getting libgcj going on cygwin. You can look in the java archives or the
cygwin-apps archives 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.
 
> In fact, it is the exponential variety of configuration options which
> make getting a good windows java compiler such a bear to wrestle with.

There aren't really that many options... mingw/win32threads;
mingw/pthreadsforwin32; cygwin/pthreads.

> I have made farays into mingw/win32 hosted on linux (i don't recall
> the specific problems encountered, off the 'top of my head'),
> 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). Have you considered a little profiling? (I'm
the cygwin pthreads maintainer. Give me a direction that you have a
problem in, and I'm happy to dig into it).

> 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.

> and now cygwin/win32
> hosted on linux (seemingly now encountering obscure .comm bugs).  

Whilst this is an option I would recommend against it. And given you
comment re: -mno-cygwin above it's actually a dead end for you, as it
will produce cygwin-linked code, not mingw linked code.

> It's
> hard to know which path to take, and difficult to justify continuing
> down any one path to overcome an obstacle, when one knows that there
> are other, untried paths, which might avoid all obstacles and provide
> a cheap win.

There are no cheap wins. AFAIK no-one has a fully supported gcc-based
java on win32/cygwin at this point. It's very frustrating because a
cygwin-aware java would be wonderful! 

You are breaking new ground, and that is often hard. However I, and I'm
sure other members in the various dependencies you've got -
gcc/mingw/cygwin/... are more that ready to provide assistance - when
you encounter specific problems. 

I suggest that you choose a path - either mingw/win32,
mingw/pthreadsforwin32 or cygwin/pthreads and then follow that path to
the end. Chopping and changing in the hope of finding a quick solution
is unlikely to work in this situation.

If you choose cygwin/pthreads, start with the cygwin-apps archives and
java@gcc archives, as most of the hard work has been done.

I'm not a java programmer myself - I dug into the gcj on cygwin issues
because Chris Faylor asked if any volunteers would like to look into
getting-it-going. Having written the requisite pthreads code to support
it, I figured I was the best person to get the ball rolling...

Good luck,

Rob

--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple