Alan Hourihane wrote:
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.On Mon, 2008-10-13 at 10:16 -0400, Mark Duckworth wrote:Miro Kropacek wrote: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 ;)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?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.
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