From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16830 invoked by alias); 3 Jan 2013 03:03:17 -0000 Received: (qmail 16804 invoked by uid 48); 3 Jan 2013 03:03:15 -0000 From: "nwourms at gmail dot com" To: java-prs@gcc.gnu.org Subject: [Bug libgcj/50895] Build failure in jni.cc Date: Thu, 03 Jan 2013 03:03:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: libgcj X-Bugzilla-Keywords: X-Bugzilla-Severity: major X-Bugzilla-Who: nwourms at gmail dot com X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: CC Message-ID: In-Reply-To: References: X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 Mailing-List: contact java-prs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: java-prs-owner@gcc.gnu.org X-SW-Source: 2013-q1/txt/msg00000.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50895 Nicholas Wourms changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |nwourms at gmail dot com --- Comment #6 from Nicholas Wourms 2013-01-03 03:03:13 UTC --- (In reply to comment #4) > A question about this build-failure. Were you using posix-threading model for > 4.6 ? I can't speak for Ruben, but now that thread models have been inextricably entwined into the core compiler, libjava really should be updated to handle mingw64's posix thread support. It shouldn't be too difficult, but does require some unraveling of the various Posix/Win32 native functions. I think the main problem is the lack of any decent signal handling in win32. As such, files such as: libjava/java/lang/natWin32Process.cc libjava/gnu/java/nio/natVMSelectorWin32.cc seem to involve event handling that is linked to Win32 threading model, specifically using the _Jv_Win32GetInterruptEvent() function. It appears that libjava/win32-threads.cc also has some similarities to the underlying pthread_cond* implementation in mingw-w64's pthreads library, so in theory it could just be a matter of porting the interrupt event handlers to posix-threads.cc to provide ifdef'd alternates to the signal handlers. Alternatively, Kai and friends at mingw-w64 could implement improved signal handling in librt, but that may be defeating the purpose of mingw.