Re: [Mingw-users] Re: [gimpwin-dev] glib under mingw32 debian cross compiler, problem with windres : gmodule-win32res.lo: file not recognized: File format not recognized

[Christopher Faylor <cgf redhat com>]

On Mon, Sep 02, 2002 at 08:45:14AM +0200, Christof Petig wrote:
>Christopher Faylor schrieb:
>>On Fri, Aug 30, 2002 at 04:03:28PM +0200, Christof Petig wrote:
>>
>>>[Summary: Cygwin is good to compile programs on win32 with minimal 
>>>porting effort, but a stable port should use MinGW]
>
>I meant build target not compiler tool chain.
>
>>Summary: If you want to ignore all of the work that has gone into
>>-mno-cygwin to make it work reliably, then use MinGW.
>
>That was not what I said. I said nothing about the cygwin toolchain but 
>about the build target.
>
>Last year the -mno-cygwin (I need C++ & libtool !!!) support was suited 
>to give me a lots of headaches and made me angry to have even tried. I 
>never got a reliable gtkmm.dll out of that! And I tried for weeks.
>
>From my experience and reading on the MinGW list:
>- there seemed to be no one at cygwin interested in reliably maintaining 
>the no-cygwin part.

I have always "reliably maintained" as much of the -mno-cygwin mechanism
as was available.  Others had volunteered to maintain the c++ part of
-mno-cygwin but they never followed through on their promises.

>- Mixing header files and import libraries was easily done within 
>cygwin. The result normally failed to link or crashed randomly

Yes, if you include -I/usr/include to get the cygwin libraries then it is
pretty easily done.  You'd have to wonder why someone would do that but...

The same thing holds for libraries.  If you try to use a cygwin library
with -mno-cygwin then the linker will oblige.  Maybe this is one of the
undocumented issues that so discouraged you but it seems rather like
common sense to me.

So, I guess you really are right.  -mno-cygwin doesn't protect users
against themselves enough.  Perhaps this is a valid criticism of
-mno-cygwin.

However, I personally, have to wonder about the thinking process of
someone who uses -mno-cygwin, notices that there are such things as
/usr/include/mingw and /usr/lib/mingw where mingw-specific files
reside but nevertheless include -lblah on the command line when they
notice that, say, fork() is missing from their mingw program.

In the case of c++ it was a real lack and could cause confusion.  I just
checked the FAQ and can't believe that it wasn't documented as not
working.  I should have suggested that years ago.

>- C++ support for -mno-cygwin was severely damaged
>
>And I was not aware that it improved _that_ much.

It has.  As I have previously said in the mingw mailing list, the test
versions of gcc that are now available for cygwin should provide
full-featured mingw support.

>I still can't believe that the cygwin toolchain will give you a
>-mno-cygwin environment without lots of (undocumented?) 'never do this'
>and 'do it this way'.

Well, belief is a funny thing.  And, documentation is as good as the
volunteers who are willing to spend time improving it.  I suppose that
you ran against a previous limitation and it didn't occur to you to
improve the process by offering a documentation patch.  That's your
right, of course.  I was working under the misapprehension that the
c++/-mno-cygwin problem was documented but apparently I was wrong.

Anyway, I've gone to some considerable effort to improve -mno-cygwin.
No reason for you to believe me but there's also no reason for you to
continue to misrepresent the state of -mno-cygwin since things have
changed and your information is now obsolete.

>Sorry, too much negative personal experience with cygwin on my side

cgf