From mint-bounce@lists.fishpool.fi Mon Oct 13 11:45:20 2008 Message-ID: <48F3693D.6080305@atari-source.org> Date: Mon, 13 Oct 2008 11:29:01 -0400 From: Mark Duckworth User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914) MIME-Version: 1.0 To: Alan Hourihane CC: Miro Kropacek , =?ISO-8859-1?Q?Vincent_Riv?= =?ISO-8859-1?Q?i=E8re?= , mint@lists.fishpool.fi Subject: Re: [MiNT] distro cross-building References: <200810110019.01757.oak@helsinkinet.fi> <48EFD0D0.3040707@atari-source.org> <200810112257.48424.oak@helsinkinet.fi> <48F1B5F6.20607@freesbee.fr> <48F2C5E3.6050900@atari-source.org> <48F35852.8070209@atari-source.org> <1223908408.13924.111.camel@jetpack.demon.co.uk> In-Reply-To: <1223908408.13924.111.camel@jetpack.demon.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ecartis-version: Ecartis v1.0.0 Sender: mint-bounce@lists.fishpool.fi Errors-to: mint-bounce@lists.fishpool.fi X-original-sender: mduckworth@atari-source.org Precedence: bulk List-help: List-unsubscribe: List-Id: X-List-ID: List-subscribe: List-owner: List-post: Alan Hourihane wrote: > On Mon, 2008-10-13 at 10:16 -0400, Mark Duckworth wrote: > >> Miro Kropacek wrote: >> >>> How would you indicate that dependent packages need updated... >>> i.e. we statically link everything to mintlib, mintlib is updated, >>> every package would then need to be updated to reflect this >>> change... how would we handle this elegantly? >>> >>> Don't know if it's elegant but the idea was to make nightly builds for >>> every package so this shouldn't be much different. We have maybe 100 >>> packages so this is task maybe for 2-3 hours with cross compiler, right? >>> >>> >> Yes but then users can't be expected to download all 100 packages every >> night because some might possibly have been rebuilt? Dynamic linking >> was designed as the best solution to this problem so it seems reasonable >> that that's what we should aim for ;) >> > > But the problem here, is that FreeMiNT (and MiNT) is designed to be TOS > compatible. You can take an executable written for MiNT and it should > (maybe with some restrictions) run on the Atari without MiNT installed > as well. You can't do that with shared libraries, obviously. > > For shared libraries we're talking about extending FreeMiNT with ELF as > an additional executable format. It's no small feat to add this, but I > guess do-able if we're willing to sacrifice TOS compatibility. > > Alan. > > I've pondered this myself and I see no choice but to abandon tos compatibility. Who really wants to run ls or pine under tos? There is no reason to. One idea I had is kind of like mkbundle for mono. Take a dynamic elf app and write a tool that will pull all the dependencies and build a static aout executable. It's certainly possible though the code for such an app might be interesting ;) mkbundle uses gcc to accomplish the feat. The problem really is that many mint applications can't run under tos or magic anyway due to dependencies. If I wanted to get GIM running under MagiC I think it would be an uphill battle trying to figure out what random unix feature was being used that MagiC/Magxnet didn't support. My plan is to study up and learn how all of this works and then: 1. Add a basic memory mapping system, enough to boot 2. Add swap 3. Beef up the memory mapping system to be a full implementation 4. ELF support 5. Dynamic linking and dlopen() and friends support. I might be missing some steps because i'm still learning but memory mapping seems like the absolute first step. Right now I'm reading a large book on linux kernel internals. I'm reading about the memory management system right now. Fascinating stuff. If we abandon certain features like swap I bet we could get things moving faster but I think swap is probably important for our platform. I would love to be able to get mint running with swap on my mega ste but of course that's not possible due to no 68020.... :-/ Why on earth are 16MB upgrades not more readily available for that platform? Thanks, Mark