RE: Is -mno-cygwin support being removed????

RE: Is -mno-cygwin support being removed????

[Dale Goudey]

[-- Attachment #1: Type: text/plain, Size: 2599 bytes --]

-mno-cygwin works just fine (for me) with cygwin 1.1.2, but additional
headers and run-time libraries are needed.  Its best to custom craft a specs
file for the compiler to do this.  Its not as simple as adding a -I
directive and a -L directive.  Something like the attached specs file would
work, but only if the headers and libraries from the mingw distribution
(latest, 27 March version) are installed where the specs file expects them.
Note that in the specs file I disable searching through the "standard system
include directories", as is needed to avoid mixing mingw and cygwin headers.
I know of no such protection from the library search paths other than making
sure that the mingw libraries are found first, and then checking that the
resulting executable does not refer to the undesired DLL's.

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



[-- Attachment #2: specs --]
[-- Type: text/plain, Size: 3063 bytes --]

*asm:


*asm_final:


*cpp:
-remap %(cpp_cpu) %{posix:-D_POSIX_SOURCE}   %{!mno-cygwin:-D__CYGWIN32__ -D__CYGWIN__}   %{mthreads: %{mno-cygwin:-D_MT}} %{mno-cygwin:-nostdinc -nostdinc++}  %{mno-cygwin:-iwithprefixbefore     ../../../../mingw/include/g++-3 } %{mno-cygwin:-iwithprefixbefore     ../../../../i386-mingw32msvc/include/mingw32 }  %{mno-cygwin:-iwithprefixbefore     ../../../../mingw/include }  %{mno-cygwin:-iwithprefixbefore     ../../../../i386-mingw32msvc/include }  %{mno-cygwin:-iwithprefixbefore    ../../i386-mingw32msvc/2.95.2/include } 

*cc1:
%(cc1_spec) 

*cc1plus:


*endfile:


*link:
%{mwindows:--subsystem windows} 		   %{mconsole:--subsystem console} 		   %{shared: %{mdll: %eshared and mdll are not compatible}} 		   %{shared: --shared} %{mdll:--dll} 		   %{shared|mdll: -e 		     %{mno-cygwin:_DllMainCRTStartup@12} 		     %{!mno-cygwin:__cygwin_dll_entry@12}}

*lib:
%{pg:-lgmon} 		  %{!mno-cygwin:-lcygwin} 		  %{mthreads:%{mno-cygwin:-lmingwthrd}} 		  %{mno-cygwin:-lmingw32 -lmoldname -lcrtdll} 		  %{mwindows:-lgdi32 -lcomdlg32} 		  -luser32 -lkernel32 -ladvapi32 -lshell32

*libgcc:
%{mno-cygwin: %{mthreads:-lmingwthrd} -lmingw32} -lgcc %{mno-cygwin: -lmoldname -lmsvcrt}

*startfile:
%{shared|mdll: %{mno-cygwin:dllcrt2%O%s}}   %{!shared: %{!mdll: %{!mno-cygwin:crt0%O%s} %{mno-cygwin:crt2%O%s}   %{pg:gcrt2%O%s}}}

*switches_need_spaces:


*signed_char:
%{funsigned-char:-D__CHAR_UNSIGNED__}

*predefines:
-Di386 -D_WIN32 %{mno-cygwin:-DWIN32 -D__WIN32__ -D__MSVCRT__ -D__MINGW32__=0.2} -DWINNT  -D_X86_=1 -D__STDC__=1  -D__stdcall=__attribute__((__stdcall__))   -D__cdecl=__attribute__((__cdecl__))   -D__declspec(x)=__attribute__((x))   -Asystem(winnt) -Acpu(i386) -Amachine(i386)

*cross_compile:
0

*version:
2.95.2

*multilib:
. ;

*multilib_defaults:


*multilib_extra:


*multilib_matches:


*linker:
collect2 %{mno-cygwin:-L/usr/lib/gcc-lib/i386-mingw32msvc/2.95.2 -L/usr/i386-mingw32msvc/lib}

*cpp_486:
%{!ansi:-Di486} -D__i486 -D__i486__

*cpp_586:
%{!ansi:-Di586 -Dpentium} 	-D__i586 -D__i586__ -D__pentium -D__pentium__

*cpp_k6:
%{!ansi:-Di586 -Dk6} 	-D__i586 -D__i586__ -D__k6 -D__k6__

*cpp_686:
%{!ansi:-Di686 -Dpentiumpro} 	-D__i686 -D__i686__ -D__pentiumpro -D__pentiumpro__

*cpp_cpu_default:
%(cpp_686)

*cpp_cpu:
-Acpu(i386) -Amachine(i386) %{!ansi:-Di386} -D__i386 -D__i386__ %{mcpu=i486:%(cpp_486)} %{m486:%(cpp_486)} %{mpentium:%(cpp_586)} %{mcpu=pentium:%(cpp_586)} %{mpentiumpro:%(cpp_686)} %{mcpu=pentiumpro:%(cpp_686)} %{mcpu=k6:%(cpp_k6)} %{!mcpu*:%{!m486:%{!mpentium*:%(cpp_cpu_default)}}}

*cc1_cpu:
%{!mcpu*: %{m386:-mcpu=i386 -march=i386} %{m486:-mcpu=i486 -march=i486} %{mpentium:-mcpu=pentium} %{mpentiumpro:-mcpu=pentiumpro}}

*mingw_include_path:
i386-mingw32msvc

*link_command:
%{!fsyntax-only:  %{!c:%{!M:%{!MM:%{!E:%{!S:%(linker) %l %X %{o*} %{A} %{d} %{e*} %{m} %{N} %{n} 			%{r} %{s} %{t} %{u*} %{x} %{z} %{Z}			%{!A:%{!nostdlib:%{!nostartfiles:%S}}}			%{static:} %{L*} %D %o			%{!nostdlib:%{!nodefaultlibs:%G %L %G}}			%{!A:%{!nostdlib:%{!nostartfiles:%E}}}			%{T*}			
 }}}}}}

Re: Is -mno-cygwin support being removed????

[Paul Baxter]

Thanks Dale for some excellent instructions.

I have successfully duplicated your results and have managed to successfully
test the FLTK v1 sources and examples with it.

One query though.

I notice the executable now links in both crtdll.dll and the newer
msvcrt.dll.

Is it possible to just have it use just msvcrt.dll?

(It appears that only _assert is used from crtdll.dll)

Hopefully this is just another instance of libraries needing to be included
in the right order.

I just use
g++ -mno-cygwin hello.cpp to get my results (expecting your doctored version
to include the right libs)

objdump -p a.exe |grep 'DLL N'
shows the necessary linked functions and dependency on crtdll.dll as well as
msvcrt.dll

--------------
// hello.cpp -- hello world example.
#include <iostream>

int main ()
{
  std::cout << "Hello world!" << std::endl;
  return 0;
}
--------------

Once again thank you very much for this temporary fix.

Paul Baxter


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

Is -mno-cygwin support being removed????

[Brian Keener]

Dale Goudey wrote:
> but only if the headers and libraries from the mingw distribution
> (latest, 27 March version)
>
Okay I'll bite.  With my problems trying to compile some things I checked 
for a newer version and was obviously looking in the wrong spots (I check 
Mumit's site) because all I could find was November and I think a  
January.  Could someone point me to the error in my ways and where I 
should have been looking for updated Mingw files.

Brian Keener
bkeener@thesoftwaresource.com





This e-mail contains privileged and confidential information solely for the use of the addressee.  If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution, copying or other use of the message and its content is strictly prohibited.  If you have received this message in error, please notify use immediately by telephone or e-mail.  
Mailto:Administrator@FultonPaper.com 

Thank you.



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

Re: Is -mno-cygwin support being removed????

[Chris Faylor]

On Wed, Jun 14, 2000 at 08:14:21PM -0400, Brian Keener wrote:
>Dale Goudey wrote:
>> but only if the headers and libraries from the mingw distribution
>> (latest, 27 March version)
>>
>Okay I'll bite.  With my problems trying to compile some things I checked 
>for a newer version and was obviously looking in the wrong spots (I check 
>Mumit's site) because all I could find was November and I think a  
>January.  Could someone point me to the error in my ways and where I 
>should have been looking for updated Mingw files.

Please direct your inquiries to the mingw mailing list.  The home page is:
http://www.mingw.org .

cgf

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

RE: Is -mno-cygwin support being removed????

[Earnie Boyd]

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

> ATTACHMENT part 2 application/octet-stream name=specs
> --
> Want to unsubscribe from this list?
> Send a message to cygwin-unsubscribe@sourceware.cygnus.com


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

[Kuo, Shyh-Hao]

Hi,

I have used the 1.1.2 version that I downloaded on sunday the 11th and I
have just managed to get -mno-cygwin to work. I think.

I am using the old B20 binaries and use the -I<directory with _G_config.h>
-L<mingwin libries> suggested by Mumit Khan.  With this setting, there is no
__impr_ptr not found but the only symbol that is not found is __imp___iob.

I am not sure if we are talking about the same problem at this stage but to
find the symbol __imp___iob, simply copy libcrtdll.a from the B20
distribution to the <mingwin libries> directory and every thing compiles
fine.

I have also checked the final import table of the executable and there is no
sign of cygwin1.dll.


Hope this will help

__________________________________________________
Shyh-hao Kuo
University of Canterbury
Masters of Engineering student
Electrical and Electronics Engineering dept.



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

Re: Is -mno-cygwin support being removed????

[Carl Thompson]

"Larry Hall (RFK Partners, Inc)" wrote:
> 
> At 01:02 PM 6/13/2000, Carl Thompson wrote:
> >depend on it.  I certainly would not say "well, I don't feel like
> >fixing my bug myself because you and your code are not important to
> >me so you should fix my code for me and if your fix is up to my
> >standards I might consider incoporating it."  I hear a lot of that
> >here.
> 
> Funny,  I've been on this list for at least 5 years and I've never
> seen this response in any of the messages I've read.

A previous post in this thread asserted that because lots of people weren't
complaining about this it wasn't important.  Your previous post asserted
that if I didn't like it "you can fix it yourself."  It's true that in this
particular thread, no one said both at once but I have certainly seen that
before on this list, certainly within the last 24 hours!

> >Not all Cygwin developers want to develop Cygwin.
> 
> A given.  But those who don't should not feel that its their
> prerogative to lambaste those who do develop Cygwin because something
> doesn't work and isn't fixed in their required time-frame.  As I'm
> sure you're aware, there is ALWAYS some problem that someone needs
> quickly.  The Cygwin team is small and can't always respond to all of
> them.

The Cygwin developers won't know what problems are important to people
unless we complain about it.  This problem is very important to me so I will
complain loudly.  That's the way it works.

> >Personally, I feel that if you release something to the open source
> >community and ask people to use it, then you have a social obligation
> >to the community to keep that product working reasonably, and that
> >includes the timely fixing of bugs that don't affect you personally. 
> >But that's just me, I guess.
> 
> I think you and Bruce are reading *WAY* too much into this.  The
> simple fact is that the person (Mumit Khan) primarily responsible for
> maintaining gcc for Cygwin is unavailable at this point.  From what
> I've heard, he won't be available until mid-month.  Allot of things
> are anxiously awaiting his return.  This is one of them.

It must be that Mumit Khan has been away for a very long time because this
has been broken for months.

> It seems inappropriate to me to assume that reports of problems are
> ignored and clandestine plots are arising just because someone hasn't
> posted a fix for the problem you found within a some specific
> time-frame of its report.  I'm sure everyone would like to see fixes
> flow very quickly.  Its just not always possible.  It doesn't mean
> some evil plot is brewing however or that the idea is to ignore
> complaints from users.

I agree with you.  I don't think there is any plot.  I do believe that the
Cygwin team isn't being particularly responsive to the needs of some of
their users by allowing the "-mno-cygwin" feature to be broken for this
long.  I don't think a months long wait for a fix for something that used to
work is reasonable, though.
 
> I don't think anyone wants people using Cygwin to have problems.  From
> what I've seen, the Cygwin team does a great job delivering new
> functionality and managing bugs.  It seems more productive to me to
> help foster an environment that promotes continued improvements and
> work than to chastise those who have been working long and hard to
> give you what you've been using.

Agreed.  The Cygwin team has done a fantastic job making Windows easier to
work with for POSIX programmers.  I am just saying that I don't like it that
a feature that I have relied on has remained broken for so long. 

I don't agree that just because Cygwin is a great free product and the
developers are selflessly helping the developer community that I shouldn't
voice my complaints nor criticize things that I think are bad.
 
> If this thread needs to continue on its current vein, its probably
> best to take it off-line.  I don't mind debating the merits or
> demerits of the Cygwin development model and approach but there's
> probably little benefit to weighing down the Cygwin list with the
> discussion.

I don't think it's fair for you to voice your opinion on-line, but tell
others that they shouldn't respond to it on-line.

I think our basic difference is that you have a "be happy with the cards
your dealt" mentality, but I have a "the squeaky wheel gets the grease"
mentality.  Both points of view are valid, but don't insist that I be like
you.
 
> Larry Hall                              lhall@rfk.com

Carl Thompson

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

Re: Is -mno-cygwin support being removed????

[MarketLogix]

Not just you man ...

I'm always reluctant to upgrade for fear that
something subtle that I've come to depend on will
stop working or, even worse, work just (slightly)
differently.  I've come to depend on this stuff
and its free so I'm not gonna bitch. Nope, I just
sit back quietly and live with it - still VERY glad
that it exists, even such that it is.

There is, no doubt, a "fix it or shut up cause its
free" attitude here. I'm not saying that its wrong
(I'm really not!) but I do believe its here & here
to stay !!!  This issue has been danced around for
the last couple of years now in many incarnations.

Its always the same, a new release, a barrage of
email problems, veteran Cygwinners telling the
hapless to stop whining & go look it up.  Hey,
I'm not that experienced with this OpenSource
stuff, maybe thats the way it s'posed to be.

Having said all that, I will attempt to upgrade again
as soon as I get well-rested and about 4-5 days with
a very low potential workload. I just don't have the
time or brain capacity to drop yet another layer down
in my toolkit to learn Cygwin in any real(or imagined)
depth. If that makes me a freeloader, then I'm sorry.
I did what I could, I bought the CD.

All told, I truly believe that this is, by far, the best
solution of its kind on the planet, AFAIK there is not
even a close second - keep up the good work.
I know you're all having fun.

Viva la Cygwin !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!


bisk


Begin forwarded message:

Mailing-List: contact cygwin-help@sourceware.cygnus.com; run by ezmlm
List-Subscribe: < mailto:cygwin-subscribe@sourceware.cygnus.com >
List-Archive: < http://sourceware.cygnus.com/ml/cygwin/ >
List-Post: < mailto:cygwin@sourceware.cygnus.com >
List-Help: < mailto:cygwin-help@sourceware.cygnus.com >,  
< http://sourceware.cygnus.com/ml/#faqs >
Sender: cygwin-owner@sourceware.cygnus.com
Delivered-To: mailing list cygwin@sourceware.cygnus.com
Date: Tue, 13 Jun 2000 10:02:32 -0700
From: Carl Thompson <cet@carlthompson.net>
X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i686)
To: "Bruce E. Wampler" <bruce@objectcentral.com>
Cc: Cygwin List <cygwin@sourceware.cygnus.com>
Subject: Re: Is -mno-cygwin support being removed????

I am one of the core developers of the FLTK GUI toolkit and we are in much
the same bind as you are.  We've relied on Cygwin as a major part of our
Windows platform support in the past and it would be nice if it worked now.

And before some zealous person says "it's open source so fix it yourself" I
don't think that's reasonable.  I don't know the Cygwin code, I've never
built the Cygwin code and I don't know the GCC code.  The Cygwin developers
could fix it better, faster and more cleanly than I if they choose to.  If
there were a bug in FLTK that caused previously working applications to
fail, I would feel honor bound to fix it because I realize that real people
depend on it.  I certainly would not say "well, I don't feel like fixing my
bug myself because you and your code are not important to me so you should
fix my code for me and if your fix is up to my standards I might consider
incoporating it."  I hear a lot of that here.

Not all Cygwin developers want to develop Cygwin.

Personally, I feel that if you release something to the open source
community and ask people to use it, then you have a social obligation to the
community to keep that product working reasonably, and that includes the
timely fixing of bugs that don't affect you personally.  But that's just me,
I guess.

Carl Thompson



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

Re: Is -mno-cygwin support being removed????

[Larry Hall (RFK Partners, Inc)]

At 01:02 PM 6/13/2000, Carl Thompson wrote:
>depend on it.  I certainly would not say "well, I don't feel like fixing my
>bug myself because you and your code are not important to me so you should
>fix my code for me and if your fix is up to my standards I might consider
>incoporating it."  I hear a lot of that here.


Funny,  I've been on this list for at least 5 years and I've never seen 
this response in any of the messages I've read.


>Not all Cygwin developers want to develop Cygwin.


A given.  But those who don't should not feel that its their prerogative
to lambaste those who do develop Cygwin because something doesn't work and
isn't fixed in their required time-frame.  As I'm sure you're aware, there
is ALWAYS some problem that someone needs quickly.  The Cygwin team is 
small and can't always respond to all of them.


>Personally, I feel that if you release something to the open source
>community and ask people to use it, then you have a social obligation to the
>community to keep that product working reasonably, and that includes the
>timely fixing of bugs that don't affect you personally.  But that's just me,
>I guess.


I think you and Bruce are reading *WAY* too much into this.  The simple
fact is that the person (Mumit Khan) primarily responsible for maintaining 
gcc for Cygwin is unavailable at this point.  From what I've heard, he won't
be available until mid-month.  Allot of things are anxiously awaiting his
return.  This is one of them.  It seems inappropriate to me to assume that
reports of problems are ignored and clandestine plots are arising just 
because someone hasn't posted a fix for the problem you found within a 
some specific time-frame of its report.  I'm sure everyone would like to 
see fixes flow very quickly.  Its just not always possible.  It doesn't 
mean some evil plot is brewing however or that the idea is to ignore
complaints from users.

I don't think anyone wants people using Cygwin to have problems.  From 
what I've seen, the Cygwin team does a great job delivering new 
functionality and managing bugs.  It seems more productive to me to help
foster an environment that promotes continued improvements and work than
to chastise those who have been working long and hard to give you what
you've been using.

If this thread needs to continue on its current vein, its probably best 
to take it off-line.  I don't mind debating the merits or demerits of the
Cygwin development model and approach but there's probably little benefit
to weighing down the Cygwin list with the discussion.


Larry Hall                              lhall@rfk.com
RFK Partners, Inc.                      http://www.rfk.com
118 Washington Street                   (508) 893-9779 - RFK Office
Holliston, MA 01746                     (508) 893-9889 - FAX
                                       (508) 560-1285 - cell phone


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

Re: Is -mno-cygwin support being removed????

[Carl Thompson]

"Bruce E. Wampler" wrote:
> 
> I've gone over all the past messages in this group, and have found
> no solution.
> 
> As far as I can tell, the -mno-cygwin option is useless in the
> latest net release version because it leads to the
> undefined symbol _impure_ptr at ld time.

I haven't seen that one (yet).  However, with more recent releases, it also
doesn't pull in the right header files with "-mno-cygwin" , "g++
-mno-cygwin" links in the Cygwin libraries anyway and exceptions don't work
(or is that your problem?).

I am one of the core developers of the FLTK GUI toolkit and we are in much
the same bind as you are.  We've relied on Cygwin as a major part of our
Windows platform support in the past and it would be nice if it worked now.

And before some zealous person says "it's open source so fix it yourself" I
don't think that's reasonable.  I don't know the Cygwin code, I've never
built the Cygwin code and I don't know the GCC code.  The Cygwin developers
could fix it better, faster and more cleanly than I if they choose to.  If
there were a bug in FLTK that caused previously working applications to
fail, I would feel honor bound to fix it because I realize that real people
depend on it.  I certainly would not say "well, I don't feel like fixing my
bug myself because you and your code are not important to me so you should
fix my code for me and if your fix is up to my standards I might consider
incoporating it."  I hear a lot of that here.

Not all Cygwin developers want to develop Cygwin.

Personally, I feel that if you release something to the open source
community and ask people to use it, then you have a social obligation to the
community to keep that product working reasonably, and that includes the
timely fixing of bugs that don't affect you personally.  But that's just me,
I guess.

> ...

> Bruce E. Wampler, Ph.D.

Carl Thompson

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

Re: Is -mno-cygwin support being removed????

[Chris Faylor]

It's being worked on.  Slowly.  In people's spare time.

The basic problem is that Mumit Khan is MIA for the time being.

cgf

On Tue, Jun 13, 2000 at 09:33:34AM -0600, Bruce E. Wampler wrote:
>I've gone over all the past messages in this group, and have found
>no solution.
>
>As far as I can tell, the -mno-cygwin option is useless in the
>latest net release version because it leads to the
>undefined symbol _impure_ptr at ld time.
>
>Given the net release is a couple of months old, that this
>problem was discussed over a month ago, and that nothing has
>been done, and that no work around has been posted means
>
>    NO ONE USES OR CARES about the -mno-cygwin option
>
>If the cygwin version of gcc is going to support -mno-cygwin,
>then the fact that it doesn't work at all in the latest release
>should be a MAJOR issue.
>
>Does the fact that cygwin is now Red Hat mean that
>support for non-cygwin apps is now going to go away?
>
>Cygwin folks - be honest with us. Let us know if
>you are dropping -mno-cygwin support so we can move on
>and support the real MinGW project and quit wasting our
>time on the cygwin release.

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

Re: Is -mno-cygwin support being removed????

[Chris Faylor]

On Tue, Jun 13, 2000 at 11:56:14AM -0500, Larry Hall (RFK Partners, Inc) wrote:
>>found as quickly as you would like is no reason to infer that the
>>"Cygwin folds" are covertly trying to remove the option.  This is an
>>open-source
>^^^^^^ folks
>
>Pardon me Cygwin folks!:-)

That's ok.  At least it wasn't "cygwin olds".  Then I really would
have been upset (the truth hurts).  :-)

cgf


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

Re: Is -mno-cygwin support being removed????

[Larry Hall (RFK Partners, Inc)]

>found as quickly as you would like is no reason to infer that the "Cygwin
>folds" are covertly trying to remove the option.  This is an open-source
 ^^^^^^
  folks

Pardon me Cygwin folks!:-)


Larry Hall                              lhall@rfk.com
RFK Partners, Inc.                      http://www.rfk.com
118 Washington Street                   (508) 893-9779 - RFK Office
Holliston, MA 01746                     (508) 893-9889 - FAX
                                       (508) 560-1285 - cell phone



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

Re: Is -mno-cygwin support being removed????

[Larry Hall (RFK Partners, Inc)]

At 09:33 AM 6/13/00 -0600, Bruce E. Wampler wrote:

>I've gone over all the past messages in this group, and have found
>no solution.
>
>As far as I can tell, the -mno-cygwin option is useless in the
>latest net release version because it leads to the
>undefined symbol _impure_ptr at ld time.
>
>Given the net release is a couple of months old, that this
>problem was discussed over a month ago, and that nothing has
>been done, and that no work around has been posted means
>
>    NO ONE USES OR CARES about the -mno-cygwin option
>
>If the cygwin version of gcc is going to support -mno-cygwin,
>then the fact that it doesn't work at all in the latest release
>should be a MAJOR issue.
>
>Does the fact that cygwin is now Red Hat mean that
>support for non-cygwin apps is now going to go away?
>
>Cygwin folks - be honest with us. Let us know if
>you are dropping -mno-cygwin support so we can move on
>and support the real MinGW project and quit wasting our
>time on the cygwin release.
>-- 
>
>Bruce E. Wampler, Ph.D.
>
>Author of the V C++ GUI Framework
>
>e-mail: mailto:bruce@objectcentral.com
>web:    http://www.objectcentral.com



This reaction seems unnecessarily harsh.  I've seen no indication, overt
or otherwise, that would give the impression that -mno-cygwin is not going
to be supported.  Just because someone hasn't addressed problems you've 
found as quickly as you would like is no reason to infer that the "Cygwin
folds" are covertly trying to remove the option.  This is an open-source
project.  If you don't like the progress in a certain area, jump in!  Maybe
you can fix it yourself and add benefit for everyone.  If you don't want
to or can't do this for some reason, perhaps providing some specific and
useful cases which demonstrate your problem and helping someone who's 
willing to look at those issues would be a good option.  Suggesting that
something clandestine is going on just because an area you think is 
important isn't getting the attention you think it deserves is unfair.
Seems to me as author of V, you should understand the way open-source works
as well as anyone.  The kind of feedback you've provided in your message
is unwarranted in this environment if you ask me...



Larry Hall                              lhall@rfk.com
RFK Partners, Inc.                      http://www.rfk.com
118 Washington Street                   (508) 893-9779 - RFK Office
Holliston, MA 01746                     (508) 893-9889 - FAX
                                       (508) 560-1285 - cell phone



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

Re: Is -mno-cygwin support being removed????

[DJ Delorie]

>     NO ONE USES OR CARES about the -mno-cygwin option

Sorry, this is just plain wrong.  I use that option, and obviously you
care about it.  I'm sure there are other examples.

> If the cygwin version of gcc is going to support -mno-cygwin,
> then the fact that it doesn't work at all in the latest release
> should be a MAJOR issue.

If it were a major issue, lots of people would be working on it
because it would effect lots of people.  Since they aren't, I can only
assume that it's only a minor issue, or at least an issue with only
minor impact.  Or perhaps they *are* working on it, but haven't taken
the time to tell you their status.

> Does the fact that cygwin is now Red Hat mean that
> support for non-cygwin apps is now going to go away?

Cygwin is not Red Hat.  *Cygnus* is now Red Hat.  Don't confuse the
two.  Support for non-cygwin apps has *always* been managed by people
*outside* of Cygnus, and will continue to be that way.  Why don't
*you* fix the problem?

> Cygwin folks - be honest with us. Let us know if you are dropping
> -mno-cygwin support so we can move on and support the real MinGW
> project and quit wasting our time on the cygwin release.

We're not dropping it.  We're just too busy to deal with it.  Anyone
else is just as able to support it as we are, so don't blame us if it
doesn't work.  Blame yourself for not taking the initiative.

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

Is -mno-cygwin support being removed????

[Bruce E. Wampler]

I've gone over all the past messages in this group, and have found
no solution.

As far as I can tell, the -mno-cygwin option is useless in the
latest net release version because it leads to the
undefined symbol _impure_ptr at ld time.

Given the net release is a couple of months old, that this
problem was discussed over a month ago, and that nothing has
been done, and that no work around has been posted means

    NO ONE USES OR CARES about the -mno-cygwin option

If the cygwin version of gcc is going to support -mno-cygwin,
then the fact that it doesn't work at all in the latest release
should be a MAJOR issue.

Does the fact that cygwin is now Red Hat mean that
support for non-cygwin apps is now going to go away?

Cygwin folks - be honest with us. Let us know if
you are dropping -mno-cygwin support so we can move on
and support the real MinGW project and quit wasting our
time on the cygwin release.
-- 

Bruce E. Wampler, Ph.D.

Author of the V C++ GUI Framework

e-mail: mailto:bruce@objectcentral.com
web:    http://www.objectcentral.com

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