From mint-bounce@lists.fishpool.fi Mon May 25 05:29:36 2009 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=ca2NVoJswwZWvx+eCwgU0esR+wd+l9nE1PZYDXVAhxI=; b=LOEYZY9FtE1mfzajNg6ue6dO4QrpMQBOeYDPg8+zuYHb6w+bwyJlQZlqIkXJWuzfvB 6nEtz+caCpGxpghHmfUEN5nu4909pvpvd7oMP9nXR7FmTcdvN1/o+tVeFDAAXyiW/IuM 3b4Ap2xGOIWxndv+m6vrP5R3RuoBSlVGksT+8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; b=o0MG7qOtubmgcDJM0Fg6AhN1VcCElpJRAOnp8lS+ZtYXv4HiwgQmtWoKgB7QqHhYW8 Y3RTwV0nx9QBAHPUkcdtqchMgX5dceY35nbn0JcVZSw4f9JVYLD27pVk7TCBKgF5zBTM kyh8DPxQHF9uLohm/6qaV8bJ58melkEMWAjyk= Message-ID: <4A1A63DE.5030600@freesbee.fr> Date: Mon, 25 May 2009 11:24:46 +0200 From: =?ISO-8859-1?Q?Vincent_Rivi=E8re?= User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: mint Subject: Re: [MiNT] math.h References: <4A19B2A3.9020704@freesbee.fr> <1243222704.22296.1.camel@server.demon.co.uk> <4A1A42EA.9070003@freesbee.fr> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-ecartis-version: Ecartis v1.0.0 Sender: mint-bounce@lists.fishpool.fi Errors-to: mint-bounce@lists.fishpool.fi X-original-sender: vincent.riviere@freesbee.fr Precedence: bulk List-help: List-unsubscribe: List-Id: X-List-ID: List-subscribe: List-owner: List-post: Miro Kropacek wrote: > 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. There is no problem. The only point to care about with a.out is to define only one function in a .c file (or several interdependent functions). This is because a .o file is either fully linked, either not linked at all. So if there are unused functions in a .c, they will take useless space in the final executable, and even worse, it will be recursively the same for the dependencies of the unused functions. The rule is: for each externally visible function in a .c, the whole contents of the .c file must be useful. If some other functions are unrelated, they should go into another .c file. If libc.a becomes bigger and bigger, there will be no problem, because only the required .o files will be linked in the executable. We just have to be careful about function dependencies, in order to avoid embedding a lot of stuff in the final executable. About the idea of merging fdlibm into the MiNTLib, I guess that Alan wants to merge the fdlibm sources into the MiNTLib source package. The MiNTLib sources currently produces libc.a, libiio.a, librpcsvc.a. After the merge, it will produce libm.a, too. The idea is to have only one source package instead of two. There will be no change for the MiNTLib users. -- Vincent Rivière