This is the mail archive of the cygwin-apps@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: gcc -mno-cygwin STL support for setup.exe?


 --- Robert Collins <robert.collins@itdomain.com.au> wrote: > 
> ===
> ----- Original Message -----
> From: "Jason Tishler" <jason@tishler.net>
> To: "Cygwin-Apps" <cygwin-apps@sources.redhat.com>
> Sent: Saturday, January 19, 2002 5:03 AM
> Subject: gcc -mno-cygwin STL support for setup.exe?
> 
> 
> > Unfortunately, I'm getting bogged down trying to add the rebase
> > functionality to setup.exe due to the lack of STL.  I am hoping that
> > I will not have to re-implement linked lists and possibly associated
> > arrays too.  I see that Rob has a list class, but I don't think that
> it
> > will meet all of my needs.
> 
> Uhmm, I've not particular objection to STL use. However keeping
> setup.exe lean and mean is an objective. We've already added 20% in size
> with the reorganisation to date. So I'll ask you to keep an eye on the
> stripped .exe size.
> 
> > About a year ago, there was some discussion about adding libstdc++.a
> to
> > Cygwin's gcc -mno-cygwin mode.  Can we revisit this issue?
> 
> I thought it was inked in if you link with g++.
> 
> Rob

For what its worth, 3.1 libsupc++.a  and libstdc++.a build natively with
mingw. (libsupc++.a contains the eh and new/delete stuff that is currently
in libgcc.a for mingw). Locale class support is missing (as it is with
cygwin/newlib), but C-locale works for me. Wide char support is missing,
because of deficiencies in C-runtime. If you want wide char with
-mno-cygwin, you'll need an auxiliary library -- like mingw's [incomplete]
libisocext.a -- to supply  C wide char support.  Iostreams work for <char>.
 In 3.1 -mno-cygwin needs the mingw32/bits headers.  Also, there may be
differences in the way the C_runtime functions are promoted into namespace
std. 

As far as size, linking in libstdc++.a has a big cost.  Some of that will
be reduced by getting rid of the extensive tree checking that is currently
on by default. Also, the -ffunction-sections, -fdata-sections (now on by
default in libstdc++.a builds)  don't really seem to add any value, but I
haven't played with them yet..

Danny  

http://my.yahoo.com.au - My Yahoo!
- It's My Yahoo! Get your own!


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]