Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com Subject: Re: Questions on patching dcrt0.cc From: Max Kaehn To: cygwin AT cygwin DOT com In-Reply-To: References: <1117064831 DOT 5390 DOT 174 DOT camel AT fulgurite> Content-Type: text/plain Message-Id: <1117139233.5390.287.camel@fulgurite> Mime-Version: 1.0 Date: Thu, 26 May 2005 13:27:13 -0700 Content-Transfer-Encoding: 7bit X-Spam-Not-Checked: Messages over 100K or from internal Electric Cloud machines are not checked X-IsSubscribed: yes On Wed, 2005-05-25 at 21:38, Igor Pechtchanski wrote: > As I understand it, the same issues arise whether cygwin1.dll is > dynamically loaded from an MSVC application or a MinGW application. > There is a simple way to compile MinGW applications on Cygwin (namely, > "gcc -mno-cygwin"). You could test your approach with a MinGW-compiled > app, and if you see the same behavior as with MSVC, the MinGW app could be > included in the testsuite. Thanks for the pointer, Igor. That was extremely helpful. I just ported the test app to mingw. The only thing I had to change was to put an #ifdef in to use GCC-style inline assembly instead of MSVC-style when it looks at the segment register. I'm still reeling in amazement at how easy that was. Wow. My hat's off to the mingw folks, and I'll be submitting the test utility (as a new subdirectory for winsup/testsuite) as mingw code (under the cygwin license) with an option in the makefile to show that it works for MSVC. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/