This is the mail archive of the crossgcc@sources.redhat.com mailing list for the crossgcc project.
See the CrossGCC FAQ for lots more information.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
On 2004-11-10 at 19:36:04 Daniel Kegel wrote: > I have a feeling gcc-3.4.3 should be ok for that range of chips > (it gets so much use on i686 it can't be too wrong there, > and I assume the others are similar enough to benefit from that). I still need to try gcc 3.4.2 on a big C++ app I'm involved with at work. This is because gcc 3.4.0 ICE'd on it, hope it is fixed now... > Likewise, glibc-2.3.3 would be a reasonable choice, at least if > you have enough RAM on the target. For low memory systems > you might need glibc-2.2.5 or even uclibc. Actually, for an embedded device I'm working on, we even use glibc 2.1.x. This is because glibc 2.2.x and higher use 2 MB of stack space per thread, whereas 2.1.x started with 16 kB, but using mmap() with MAP_GROWSDOWN. Actual commit here: http://sources.redhat.com/cgi-bin/cvsweb.cgi/libc/linuxthreads/manager.c.diff?r1=1.54&r2=1.55&cvsroot=glibc&f=h So if you don't have swap, as is likely on such a device, you run out of memory very quickly, if you want to have a multithreaded application... Anyway, it might be better to use another libc, but then the application programmers might start complaining about not having glibc's bells and whistles. :)
Attachment:
pgp00000.pgp
Description: PGP signature
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |