From fnaumann@mail.cs.uni-magdeburg.de Tue Aug 10 23:22:23 2004 Date: Tue, 10 Aug 2004 23:16:19 +0200 From: Patrice Mandin To: Mint list Subject: Re: [MiNT] Loadable libraries urgently needed (was: Coreutils) Message-Id: <20040810231619.7b63c158.mandin.patrice@wanadoo.fr> In-Reply-To: <1092165758.6817.10.camel@pikachu.atari-source.com> References: <1092165758.6817.10.camel@pikachu.atari-source.com> Organization: Chez moi X-Mailer: Sylpheed version 0.9.11 (GTK+ 1.2.10; i586-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15 Delivered-To: mint@fishpool.com Delivered-To: mint@lists.fishpool.fi X-ecartis-version: Ecartis v1.0.0 Sender: mint-bounce@lists.fishpool.fi Errors-to: mint-bounce@lists.fishpool.fi X-original-sender: mandin.patrice@wanadoo.fr Precedence: bulk List-help: List-unsubscribe: List-ID: X-List-ID: X-Milter: ClamAV 0.70/0.70kjel X-Milter: milter-regex 1.5jel X-Milter: ClamAV 0.70/0.70kjel X-Milter: milter-regex 1.5jel Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by prinz.cs.uni-magdeburg.de id i7ALLrYS026725 Le Tue, 10 Aug 2004 15:22:38 -0400 Mark Duckworth a écrit: > This is a bit of a touchy subject but this coreutils, since we are > linking statically is costing about 800+K for something like ls where as > this tool used to be only 100-200K. This means the coreutils binary RPM > is a whopping 47 megs! I've been trying to shrink binary sizes but to > no avail. I must be missing something. Unfortunately, it just shows how we urgently need to make libraries loadable (and shareable using MMU), so we don't have to recompile all packages depending on a library when it is updated. Does anybody else think we should stop porting new software, and concentrate on making this possible ? I know it would need a bit of support from the kernel, but modifying the a.out binary format we uses, to add a section relative to external dependencies should be possible. There was a new header added to support GNU binutils/gcc a.out format in an easier manner. The switch to ELF format would be costly in terms of time, so maybe extending the GEMDOS a.out format is a better option. My proposal: - 1. Add a new section, which marks external addresses (like the relocation table), and give the function name, and the library name to use. - 2. On load, either the kernel, or a custom crt0.o seeks to load needed libraries. In this case, we repeat step 2 recursively on this library, taking care of not loading the same library twice -> infinite loop. - 3. Once loaded, browse the section, and retrieve the needed pointers from the loaded library. - 4. ELF format defines _init() and _fini() to initialize and close properly a library, so we can also use these names. -- Patrice Mandin WWW: http://membres.lycos.fr/pmandin/ Programmeur Linux, Atari Spécialité: Développement, jeux