Mail Archives: cygwin/2005/11/10/05:23:05
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/
- Raw text -