[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [MiNT] C++
On Tue, 5 Nov 2013 11:34:56 , Adam Klobukowski <adamklobukowski@gmail.com> wrote:
> 2013/11/5 <p.slegg@scubadivers.co.uk>
>
> >
> >
> > ---- Original Message ----
> > From: Miro Kropá?ek <miro.kropacek@gmail.com>
> > To: "Peter Slegg" <p.slegg@scubadivers.co.uk>
> > Cc: "MiNT Mailing List" <mint@lists.fishpool.fi>
> > Sent: Tue, Nov 5, 2013, 12:29 AM
> > Subject: Re: [MiNT] C++
> >
> > >> > How about providing the most used libraries with a trap #x interface
> ?
> > >>
> > >> > This way applications only link comparatively small code like they
> > >> > already do for BIOS/XBIOS and GEMDOS calls while the bulk of the
> > actual
> > >> > lib code runs in one big lump that is loaded only once into memory?
> > >>
> > >>Is it possible under Mint to compile an application without static
> > >>linking and/or to compile libs that could be linked dynamically later ?
>>
> > >>I was wondering if the resulting binaries could be wrapped in some way
> > >>so that when started the libs are loaded and then the application is run
> > >>a bit like a self-extracting archive.
> > >
> > >
> > >You know, reading mails like this makes me think that there's no bigger
> > problem than having the option to load dynamic >libraries under FreeMiNT
> :)
> > I think "everyone" who uses FreeMiNT+XaAES for anything serious these day
> s
> > (like compilation,
> > >running command line tools in general) has a powerful machine with 64+ M
> B
> > RAM and... when was the last time you ran out of
> > >memory?
> >
> >
> > I have 144MB and I last ran out about a month ago. Even closing as many
> > apps as possible didn't
> > help.
> >
> >
> The problem is not with the amount of free memory, but with memory
> fragmentation.
>
>
> > However, I am not suggesting SHARED libs just LOADABLE ones.
> >
> >
> Loadable libs exist today in userspace and you could also use SLBs. Even
> so, they will not be solution for your problem.
>
>
> > From my user point of view it makes little difference but for the
> > developers
> > it would make a big difference if lib changes could be implemented in
> > everything
> > without a massive re-compile effort.
>
>
> SLBs (IMO the only sensible solution) are not supported by gcc and I doubt
> they'll ever be.
>
>
> >
> > Obviously in the long term it would be nice to use proper linked libs but
> > getting
> > there is difficult. Other systems used interim measures over many years.
> > Why not Mint ?
> >
>
> We have interim measures: SLBs and userspace loadable libs. They are a
> solution for some problem, but not for your problem.
>
> What MiNT really needs is ELF support with proper address space separation.
>
Why would fragmentation be any worse than static linking ?
What I am suggesting is that an app starts loads the libs it needs.
When the app closes, the apps are closed as well. They are not shared,
just loaded for each app that needs them.
I wouldn't expect gcc to support slb but could an elf (or whatever)
be wrapped to look work like an slb ?
As you can tell this isn't my field of expertise so I am just
throwing a few ideas about.
Regards,
Peter