Re: boost program_options library with cygwin

[Thomas Porschberg <thomas dot porschberg at osp-dd dot de>]

Hi Brian,

thanks for your explanation. I'm quite new to cygwin/mingw
and so my questions are probably very basic.
The idea on my side is to have sources which can be compiled
as an cygwin application or as a mingw/windows application.
The working environment is cygwin. The distinction between
windows/mingw and cygwin at application compile level is done 
by specify "-mno-cygwin".
The problems arised by integrate external libraries like boost
or cppunit. I used the libraries provided by http://cygwin.com.
I encountered a first problem by creating my cppunit test 
as an mingw/windows application. I got unresolved linker errors
because libcppunit was built as cygwin-library. I resolved the
problem by compiling the library from sources with -mno-cygwin
flag. And then I used this library for both, my application
cygwin-build and my application mingw-build.
If I understand you right, this is at least dangerous. I have
to maintain to different cppunit libraries for both builds.
However it worked for me ?!
The same game with boost. I first used the filesystem-sub-library
from this package for my mingw build, without linker error.
Later I introduced program_options too and got the mentioned
linker errors. I resolved this problem by applying the procedure
I mentioned.
However I'm still uncertain. What is the recommended way to
build a mingw/windows application with external libraries using
the cygwin environment ?
Can someone provide a recipe what I have to check if I integrate
a new external library to my project ?

Thomas

On Wed, Nov 09, 2005 at 08:29:57AM -0800, Brian Dessent wrote:
> 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/
> 

-- 


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