This is the mail archive of the
cygwin-apps@cygwin.com
mailing list for the Cygwin project.
Re: gcc -mno-cygwin STL support for setup.exe?
- From: Danny Smith <danny_r_smith_2001 at yahoo dot co dot nz>
- To: Cygwin-Apps <cygwin-apps at sources dot redhat dot com>
- Date: Sat, 19 Jan 2002 15:57:24 +1100 (EST)
- Subject: 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!