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 Message-ID: <43722405.F29D93A2@dessent.net> Date: Wed, 09 Nov 2005 08:29:57 -0800 From: Brian Dessent MIME-Version: 1.0 To: cygwin AT cygwin DOT com Subject: Re: boost program_options library with cygwin References: <20051109160408 DOT GB5162 AT porschberg DOT osp-dd DOT de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Reply-To: cygwin AT cygwin DOT com Thomas Porschberg wrote: > This is of course nice but can someone give an explanation ? What do you want an explantion of? The fact that you can't mix and match Cygwin and non-Cygwin objects in an executable? That's because mingw and Cygwin use different C runtimes. It boils down to the fact that you're compiling objects against one CRT's headers but at link time trying to link them to a different CRT's library. This is bad news, because the two CRTs are certainly not ABI compatible, so function arguments will be all kinds of messed up, leading to SEGV crashes. And that's if you even get it to link, which is exceedingly rare. Most of the time you won't, because you will have accidently used a function somewhere that exists in one CRT but not the other. Or because the two CRTs used different and incompatible #defines internally to implement things like 'assert' or 'environ', or whatever. The take-away is that -mno-cygwin is not a magic bullet that just somehow magically makes objects that don't depend on Cygwin but otherwise leaves everything the same. It switches the build environment to something completely different. Brian -- 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/