This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: boost program_options library with cygwin

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


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:
> Problem reports:
> Documentation:
> FAQ:         


Unsubscribe info:
Problem reports:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]