From mint-bounce@lists.fishpool.fi Mon Aug 8 15:27:09 2005 X-Original-To: fnaumann@mail.boerde.de Delivered-To: fnaumann@mail.boerde.de Message-ID: <42F75D14.4040205@imperia.net> Date: Mon, 08 Aug 2005 15:24:36 +0200 From: Guido Flohr User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en MIME-Version: 1.0 To: Howard Chu Cc: Mark Duckworth , Mint List Subject: Re: [MiNT] binutils References: <1123195526.13267.0.camel@mduckworth.phillypark.net> <42F29C07.5060907@highlandsun.com> In-Reply-To: <42F29C07.5060907@highlandsun.com> X-Enigmail-Version: 0.91.0.0 X-MIMETrack: Itemize by SMTP Server on juniorwhopper/Imperia/de(Release 5.0.12 |February 13, 2003) at 08/08/2005 03:24:39 PM, Serialize by Router on juniorwhopper/Imperia/de(Release 5.0.12 |February 13, 2003) at 08/08/2005 03:24:39 PM, Serialize complete at 08/08/2005 03:24:39 PM Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig64D86DBB75633843B382860E" X-ecartis-version: Ecartis v1.0.0 Sender: mint-bounce@lists.fishpool.fi Errors-To: mint-bounce@lists.fishpool.fi X-original-sender: guido@imperia.net Precedence: bulk List-help: List-unsubscribe: List-Id: X-List-ID: 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: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig64D86DBB75633843B382860E Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Hi, Howard Chu wrote: > If you guys are investigating new binutils and new object file formats,= =20 > then now is a good time to invest in developing a re-linkable executabl= e=20 > file format. ELF may be a good starting point; as noted already you can= =20 > put whatever sections you want into an ELF file. You could try keeping = > the ELF .relo section and just append it to the TOS file image, with an= =20 > appropriate pointer to it in the standard TOS symbol table. I see no real benefit from changing the format of the executables. The=20 current format provides everything you need, including the relocation=20 information. Why change that? The real problem is the lack of dynamic linking facilities which has=20 nothing to do with the container format of executables. I would rather=20 investigate in the format and logic of shared libraries. If you agree=20 with me, that MiNT will not see "real" virtual memory management before=20 the heat death of the universe, and limit expectations to dynamic=20 linking (as opposed to sharing code sections in memory between=20 processes), I can't see why the Perl interpreter shouldn't be able to=20 dynamically load extensions. Ciao, Guido --=20 Imperia AG, Development Leyboldstr. 10 - D-50354 H=FCrth - http://www.imperia.net/ --------------enig64D86DBB75633843B382860E Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQFC910UOo0HNPWNDz0RAoASAJ95JVcZNyjT3ESL6+E3EWp6M2TzeACfS9CF DI1YkRLLRWQAvi4Dsa45MLo= =ZvMQ -----END PGP SIGNATURE----- --------------enig64D86DBB75633843B382860E--