Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT sourceware DOT cygnus DOT com>
List-Archive: <http://sourceware.cygnus.com/ml/cygwin/>
List-Post: <mailto:cygwin AT sourceware DOT cygnus DOT com>
List-Help: <mailto:cygwin-help AT sourceware DOT cygnus DOT com>, <http://sourceware.cygnus.com/ml/#faqs>
Sender: cygwin-owner AT sourceware DOT cygnus DOT com
Delivered-To: mailing list cygwin AT sourceware DOT cygnus DOT com
Message-ID: <394147A8.93BBE5CB@carlthompson.net>
Date: Fri, 09 Jun 2000 12:38:16 -0700
From: Carl Thompson <cet AT carlthompson DOT net>
X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i686)
MIME-Version: 1.0
To: "Parker, Ron" <rdparker AT butlermfg DOT com>,
        Cygwin List <cygwin AT sourceware DOT cygnus DOT com>
Subject: Re: Extreme newbie here...
References: <20000609173105 DOT 8C9D0803A AT carlthompson DOT net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


"Parker, Ron" wrote:

> ...

> > (Cygwin did have the ability to generate Windows programs, but it is
> > unfortunately broken in recent releases.)
> 
> Actually, I have been investigating this.  GCC should work just fine
> with -mno-cygwin for C code.  It also works pretty well for C++ code. 
> I have only found two problems so far.
> 
> The first problem is minor and involves the way g++ links with libc.a
> and libm.a.  I have a modified g++.exe that I can send to peaple that
> need it until I can release an update gcc package.  (Mumit is still
> the "real" maintainer, he is just unavailable until mid-month.)
> 
> The second problem is more of an issue.  Currently when the compiler
> driver is called with -mno-cygwin it cannot link code that uses
> exceptions.  I am looking into this.  I have not had a chance to
> validate whether or not this worked with B20.x, a given DLL snapshot,
> and/or some version of Mumit's GCC release.  I assume it did, but
> possibly required his mingw-extras package.  This does not appear to
> work with the net release.

I also noticed that it seems to pulling the incorrect header files.  I
think Paul Baxter wrote that he had a workaround for this but I don't
think he wrote what exactly it was...
 
> The other issue that arises in some packages like FLTK is that the
> cygwin 1.1.x release uses a newer version of gcc that adheres more
> strictly to the C++ standard and as a result will not accept some code
> that earlier versions would accept.  This will require changes to the
> package's source code.  An example of this kind of problem is shown
> below:
> 
> gcc -I /usr/i686-pc-cygwin/include/mingw -I.. -I. -O2 -fforce-mem
> -fforce-addr -fcaller-saves -fomit-frame-pointer -DWIN32 -mno-cygwin
> -DWIN32 -mno-cygwin Fl_Widget_Type.cxx -c
> Fl_Widget_Type.cxx: In method \
> `void Fl_Widget_Type::read_property(const char *)': \
> Fl_Widget_Type.cxx:2007: cannot resolve overloaded function `name' \
> based on conversion to type `const char *'

Oops.  I should have mentioned in my email that due to recent internal
changes in FLTK compilation in that directory is very broken on _every_
platform.  If you want the try the FLTK pre alpha snapshots out, please
ignore the "fluid" directory.

> ...

Thanks,
Carl Thompson

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe AT sourceware DOT cygnus DOT com