From mint-bounce@lists.fishpool.fi Mon May 25 04:14:31 2009 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=pojOThxlWuRxWHN9VlMR9QlW9erUYI3QUKrn7d9H7QE=; b=yA0G85+00321Lzv6erOggA52H84lA9/NSFcMrW4nsZrsTPaPjC+QAzdJ8b6a4zfJQy 7WCst7qKMKG2NKqd/MXGdcaG9TkcumSVLe/QHKIZu3QCSWT2Q+tRZ4LezsJ4vD4pAFl3 ek33ktyC2/RyGfco341n8+nwjRohdrtVNZjFI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=WkjBfv1ct1CQDAoltrQYjpF+YfUrqKPrD/Oy81zSWoh5L4GYxJJz62r3+9OEO1lvV0 jy9hSVrHx4wxBL+NngYfJisl0Y52pwWfNctWeXM1ABHcO1MrTwoqfGH2VtcHUVBfICv7 xFpA/dA2BsJpIQwe5IoR6kNxcXubmQALu7ymE= MIME-Version: 1.0 In-Reply-To: <4A1A42EA.9070003@freesbee.fr> References: <4A19B2A3.9020704@freesbee.fr> <1243222704.22296.1.camel@server.demon.co.uk> <4A1A42EA.9070003@freesbee.fr> Date: Mon, 25 May 2009 10:11:47 +0200 Message-ID: Subject: Re: [MiNT] math.h From: Miro Kropacek To: =?ISO-8859-1?Q?Vincent_Rivi=E8re?= Cc: mint Content-Type: multipart/alternative; boundary=000e0cd2496860853c046ab8291f X-ecartis-version: Ecartis v1.0.0 Sender: mint-bounce@lists.fishpool.fi Errors-to: mint-bounce@lists.fishpool.fi X-original-sender: miro.kropacek@gmail.com Precedence: bulk List-help: List-unsubscribe: List-Id: X-List-ID: List-subscribe: List-owner: List-post: --000e0cd2496860853c046ab8291f Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit > > I've already got fdlibm in the CVS, but I'd be happy with bringing >> fdlibm into MiNTlib and replacing math.h from that so our MiNTlib can >> provide both libc & libm by default. >> > > You're right, we must continue that way. So the standard library will be > complete, there will be no divergence between libc and libm. Only one note: as far as I remember, since we're still using that a.out format even for object files, does not this implies the size of libc.a will grow no matter if the user uses 1/10 or that math lib or 1/2? The final binary of simple hello world is quite huge even in the present. -- MiKRO / Mystic Bytes http://mikro.atari.org --000e0cd2496860853c046ab8291f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I've already got fdlibm in the CVS, but I'd be happy with bringing<= br> fdlibm into MiNTlib and replacing math.h from that so our MiNTlib can
provide both libc & libm by default.

You're right, we must continue that way. So the standard library will b= e complete, there will be no divergence between libc and libm.
= Only one note: as far as I remember, since we're still using that a.out= format even for object files, does not this implies the size of libc.a wil= l grow no matter if the user uses 1/10 or that math lib or 1/2? The final b= inary of simple hello world is quite huge even in the present.

--
MiKRO / Mystic Bytes
http://mikro.atari.org
--000e0cd2496860853c046ab8291f--