From mint-bounce@lists.fishpool.fi Sun Sep 17 10:14:56 2006 X-Original-To: fnaumann@mail.boerde.de Delivered-To: fnaumann@mail.boerde.de From: Eero Tamminen Organization: Koti To: mint@lists.fishpool.fi Subject: Re: [MiNT] glibc for m68k/mint? Date: Sun, 17 Sep 2006 11:11:26 +0300 User-Agent: KMail/1.6.2 Cc: Howard Chu , Adam K?obukowski , mint@fishpool.com References: <200609170306.23477.miro.kropacek@gmail.com> <450CEF39.3020206@gabo.pl> <450CFF50.5030109@highlandsun.com> In-Reply-To: <450CFF50.5030109@highlandsun.com> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit Message-Id: <200609171111.27022.oak@helsinkinet.fi> X-ecartis-version: Ecartis v1.0.0 Sender: mint-bounce@lists.fishpool.fi Errors-To: mint-bounce@lists.fishpool.fi X-original-sender: oak@helsinkinet.fi Precedence: bulk List-help: List-unsubscribe: List-Id: X-List-ID: List-subscribe: List-owner: List-post: X-Virus-Scanned: by amavisd-new at relay.boerde.de X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on relay.boerde.de X-Spam-Status: No, hits=-1.0 tagged_above=-50.5 required=7.0 tests=BAYES_00 X-Spam-Level: Hi, On Sunday 17 September 2006 10:54, Howard Chu wrote: > >> Glibc depends heavily upon the linux kernel as far as I know. Without > >> modern kernel interfaces, no modern libc. We need virtual memory. I > >> thought you were working on that :-P > > > > I don't think that dependency is so heavy - libc supports also Hurd > > and some othere (don't remember now) systems. So it may be pretty > > portable. Btw. it supports m68k out-of-the-box. > > Aren't there still archives of this list? These questions have been > asked and answered before. glibc is several times larger than mintlib, > and quite a bit slower. It also didn't exist when we first started > developing MiNT, gcc, and the associated tools. Perhaps people running > MiNT on fast 68K emulators today don't care so much, but even the > smallest program linked with glibc would eat up a sizable chunk of an > Atari ST's RAM... Much better would be to use uClibc: http://www.uclibc.org/ It actually contains parts of MiNTlib I think and it has been done keeping size in mind. The downside of it is that its ABI changes yearly, but that shouldn't be a problem if all libraries link it statically... ;-) - Eero