Re: Is -mno-cygwin support being removed???? (What th'?)

Re: Is -mno-cygwin support being removed???? (What th'?)

[Earnie Boyd]

--- Chris Faylor <cgf@cygnus.com> wrote:
> If I am understanding this correctly, it sounds like there is a newer
> version of mingw which should be merged back into the cygwin
> distribution.  Either that or I should just rip out all of this mingw
> stuff and let the mingw maintainers deal with the problem.
> 

Cool down Chris.  The problem here that Dale has rightly corrected, IMHO, is
that the -mno-cygwin switch is pulling in header files from the
Cygwin/usr/include directory and thus requiring the cygwin1.dll.  There has
always been a MinGW distribution since the introduction of the -mno-cygwin
switch and I know that you're aware of that, however the -mno-cygwin switch was
meant to allow the Cygwin GCC to build executables without the need for the
cygwin1.dll.

I myself choose to use the MinGW GCC to build Windows Native Applications (WNA)
instead of the -mno-cygwin switch because of the reasons that has caused this
discussion.  It has always been my belief that the -mno-cygwin switch should be
treated more as a cross-compile which Dale has given instructions to setup.

Regards,

=====
---
   Earnie Boyd: < mailto:earnie_boyd@yahoo.com >
            __Cygwin: POSIX on Windows__
Cygwin Newbies: < http://www.freeyellow.com/members5/gw32/index.html >
           __Minimalist GNU for Windows__
  Mingw32 List: < http://www.egroups.com/group/mingw32/ >
    Mingw Home: < http://www.mingw.org/ >

__________________________________________________
Do You Yahoo!?
Yahoo! Photos -- now, 100 FREE prints!
http://photos.yahoo.com

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Is -mno-cygwin support being removed???? (What th'?)

[David Robinow]

--- Chris Faylor <cgf@cygnus.com> wrote:
> If I am understanding this correctly, it sounds like
> there is a newer
> version of mingw which should be merged back into
> the cygwin
> distribution.  Either that or I should just rip out
> all of this mingw
> stuff and let the mingw maintainers deal with the
> problem.
 mingw, cygwin, fltk, and I think (I don't use it) V,
are all under continuous development. 
> Why is it that no one has mentioned this "new
> version" of mingw in the
> last two months?  If this solves the ills of all of
> the -mno-cygwin
> users then why are we wasting our time tracking down
> the problems that
> people are reporting?  Why are the cygwin
> maintainers taking heat for
> being "unresponsive" if there is an actual solution
> available?
 The solution was unknown until the recent post by
Dale Goudey.
> 
> I don't mind making a new gcc release myself but I
> sure don't want to
> have to be a detective, tracking down stuff that I'm
> not particularly
> interested in.  With Mumit gone is anyone interested
> in taking the
> responsibility for this stuff?  I don't see any
> reason for me to worry
> about it if there is already solutions but no one
> has been proactive
> enough to inform the readers of
> cygwin@sourceware.cygnus.com until
> now.
 I believe, I'm just guessing here, that Mumit saw no
reason to continually update the -mnocygwin support
when there was a relatively good 20.1 solution already
and nothing was broken.  I speculate that this would
have all been straightened out a month ago except that
Mumit Khan's absence unfortuitously coincided with a
major Cygwin upgrade.  The mingw people are
unfortunately in the same somewhat helpless situation
as Cygwin in that they have relied on one individual,
Mumit Khan, for the Cygwin integration.
 This whole situation has been exacerbated by the fact
that FLTK has just had another release and is fast
approaching a new major upgrade to 2.0.
 As a user, but alas not much of a contributor, of
these products, I appreciate all your hard work and
understand if people get a bit grumpy during critical
periods.  It would be nice though if everybody could
calm down a bit.
> 
> Probably the best solution is to forward all
> -mno-cygwin requests to
> the the mingw mailing list where they belong.
 I don't know how much my opinion, as a
non-contributor, matters, but this actually seems like
a good idea to me.
> 
> cgf
> 
> On Wed, Jun 14, 2000 at 07:26:36AM -0700, Earnie
> Boyd wrote:
> >IMHO, this is the correct way to support this
> switch.
> >> Dale Goudey


__________________________________________________
Do You Yahoo!?
Yahoo! Photos -- now, 100 FREE prints!
http://photos.yahoo.com

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Is -mno-cygwin support being removed???? (What th'?)

[Chris Faylor]

If I am understanding this correctly, it sounds like there is a newer
version of mingw which should be merged back into the cygwin
distribution.  Either that or I should just rip out all of this mingw
stuff and let the mingw maintainers deal with the problem.

Why is it that no one has mentioned this "new version" of mingw in the
last two months?  If this solves the ills of all of the -mno-cygwin
users then why are we wasting our time tracking down the problems that
people are reporting?  Why are the cygwin maintainers taking heat for
being "unresponsive" if there is an actual solution available?

I don't mind making a new gcc release myself but I sure don't want to
have to be a detective, tracking down stuff that I'm not particularly
interested in.  With Mumit gone is anyone interested in taking the
responsibility for this stuff?  I don't see any reason for me to worry
about it if there is already solutions but no one has been proactive
enough to inform the readers of cygwin@sourceware.cygnus.com until
now.

Probably the best solution is to forward all -mno-cygwin requests to
the the mingw mailing list where they belong.

cgf

On Wed, Jun 14, 2000 at 07:26:36AM -0700, Earnie Boyd wrote:
>IMHO, this is the correct way to support this switch.
>
>Earnie.
>--- Dale Goudey <goudey@earthlink.net> wrote:
>-8<-
>> With the right specs file, 1.1.2 seems to work find for what I have tried
>> (C, C++, fortran).  No warranties.  The enclosed specs file is a bit of a
>> hack, and some of the hacks may break for future releases of gcc/cygwin.
>> There is no good definition/specification for the specs file that I am aware
>> of other than the source code, so I assume that the specs file is fair game
>> for reformatting with each revision of the compiler.
>> 
>> I use the following mingw packages
>>    gcc-2.95.2-1-msvcrt.zip
>>       (use the lib/gcc-lib/i386-mingw32msvc therein by moving or copying
>>        it into /usr/lib/gcc-lib to make it parallel to
>> /usr/lib/gcc-lib/i686-pc-cygwin
>>                   (this gives you /usr/lib/gcc-lib/i386-mingw32msvc)
>> 
>>        use the include/g++-3 therein by moving or copying it
>>        into /usr/mingw/include                 (this directory must be
>> created)
>> 
>>        and use the files i386-mingw32msvc/include/*.h therein by moving or
>>        copying them into /usr/mingw/include
>>       )
>>    bin-msvcrt-2000-03-27.zip
>>       (unpacking under /usr, and then
>>   THIS IS TRICKY:
>>            from a true MSDOS shell (using command.com or cmd.com), go into
>> /usr/bin.
>>            If you see a single file called mingwm10.dll move it to /bin
>>        You must then also undo some damage to the file structure caused by
>> the
>>        unpack by going into the /usr directory and remove the undesired bin
>> directory:
>>                rd bin
>>        You may now exit the MSDOS shell.
>>        from a cygwin shell (like an rxvt window)
>>              cp -a /usr/i386-mingw32msvc/lib/*.o /usr/i686-pc-cygwin/lib
>>       )
>> 
>> It works for me.  100k lines of C/C++/fortran do just fine.
>> 
>> I expect that the above hacks will be unnecessary and probably broken when
>> Mumit Khan  returns to the scene.
>> 
>> Hope this helps.
>> Dale Goudey

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com