On Thu, 2007-12-06 at 23:00 +0100, Jacek M. Holeczek wrote:
> > I can (and I'm inclined to) make the DLLs available as a separate
> > download. There would be two advantages to this : you could benefit, and
> > it would get tested.
>
> Why not put them in, by default, and let the people choose whi
> I can (and I'm inclined to) make the DLLs available as a separate
> download. There would be two advantages to this : you could benefit, and
> it would get tested.
Why not put them in, by default, and let the people choose which one they
want to use?
If you really want to make a new binary rele
On Wed, 2007-12-05 at 08:53 +0100, Jacek M. Holeczek wrote:
> > Doesn't use of a DLL remove most of this whole issue ?
>
> Yes, I believe so.
> However, is there any definite plan to switch to shared libstdc++ for
> the mingw32ce target?
Pedro recently asked not to put this in the release because
> Doesn't use of a DLL remove most of this whole issue ?
Yes, I believe so.
However, is there any definite plan to switch to shared libstdc++ for
the mingw32ce target?
Jacek.
-
SF.Net email is sponsored by: The Future of Lin
On Mon, 2007-12-03 at 13:42 -0500, Kevin O'Connor wrote:
> I meant using gcc instead of g++ for c++ code - gcc will work, it just
> wont pull in libsupc++.a/libstdc++.a by default. If one goes through
> the trouble of compiling with -fno-exceptions then they probably don't
> want libsupc++.a to be
Hi Jacek,
On Mon, Dec 03, 2007 at 06:57:35PM +0100, Jacek M. Holeczek wrote:
> > Jacek, I think it would be better to reword your FAQ so that it states
> > using -fno-exceptions, -fno-rtti, and using gcc instead of g++.
> > Anything less and even simple c++ programs are going to end up pulling
> >
Hi,
I don't have the cegcc at hand now, so I can only say what I recall.
> > undefined reference to `vtable for __cxxabiv1::__si_class_type_info'
> > undefined reference to `vtable for __cxxabiv1::__vmi_class_type_info'
> > undefined reference to `vtable for __cxxabiv1::__class_type_info'
> > und
On Sun, Dec 02, 2007 at 11:51:18AM -0500, Kevin O'Connor wrote:
> When I went through this exercise, I just started commenting out stuff
> to see what was forcing the exceptions into the exe. I got down to
> the following stuff still needed from libsupc++.a:
>
> undefined reference to `vtable for
On Sun, Dec 02, 2007 at 02:41:17AM +, Pedro Alves wrote:
> Kevin O'Connor wrote:
> > Unfortunately, try as I might, I could not get haret (see
> > http://www.handhelds.org/moin/moin.cgi/HaRET) to shrink with
> > -fno-exceptions. As a guess, it looks like anything that requires
> > libsupc++.a
Kevin O'Connor wrote:
> Hi Jacek,
>
> Thanks for providing the FAQ.
>
> I found answer 10 to be very informative. I too had noticed the 40K
> of baggage that the c++ compiler appends to programs. However, I
> didn't know that the -fno-exceptions flag could reduce this.
>
> Unfortunately, try a
Hi Jacek,
Thanks for providing the FAQ.
I found answer 10 to be very informative. I too had noticed the 40K
of baggage that the c++ compiler appends to programs. However, I
didn't know that the -fno-exceptions flag could reduce this.
Unfortunately, try as I might, I could not get haret (see
ht
See question/answer 10 in my FAQ for explanations (in short, the 40kB
size difference came from the "exception handling" code).
Best regards,
Jacek.
-
SF.Net email is sponsored by: The Future of Linux Business White Paper
from
On Mon, 2007-11-05 at 18:01 +0100, Jacek M. Holeczek wrote:
> A simple ".exe" compiled with MS C++ is about 3 kB long, the same code
> compiled with CeGCC is about 40 kB long.
> Similarly, a ".dll" compiled with MS C++ is about 39 kB long, the same
> code compiled with CeGCC is about 89 kB long.
>
Hi,
I've got a strange question.
A simple ".exe" compiled with MS C++ is about 3 kB long, the same code
compiled with CeGCC is about 40 kB long.
Similarly, a ".dll" compiled with MS C++ is about 39 kB long, the same
code compiled with CeGCC is about 89 kB long.
In both cases, the CeGCC produces sig
14 matches
Mail list logo