RE: [MiNT] shared libs

["Julian Reschke" <reschke@muenster.de>]

> From: owner-mint@fishpool.com [mailto:owner-mint@fishpool.com]On Behalf
> Of Guido Flohr
> Sent: Saturday, February 19, 2000 1:06 AM
> To: MiNT mailing list
> Subject: [MiNT] shared libs
>
>
> On Fri, Feb 18, 2000 at 08:37:01PM +0100, Jo Even Skarstein wrote:
> > On Fri, 18 Feb 2000 15:00:51 +0100 (CET), Konrad M. Kokoszkiewicz wrote:
> >
> > > number of shared libraries, which would be comon and handy. Example, a
> >
> > Indeed, and the first one should be libc :-) I have been playing around
> > with SLBs a little bit, trying to make a simple GEM-library (just some
> > dialog-stuff) just for the sake of it. However, since I lack a libc it's
> > pretty difficult to write anything decent, the best I could do was to
> > lock the entire lib whenever it was entered. Not the best solution...
>
> I agree.  And if you have a look at the ChangeLog of the MiNTLib you will
> find that I have done quite a few efforts in this direction.  You will see
> that a lot of "problem functions" are now internally based on reentrant
> functions (and these reentrant functions already provide quite a bit of
> thread-safety to those who are interested).
>
> I also keep in mind other things that are needed for shared libs but we
> still lack quite a few of them.  For instance, our gcc is not even able to
> produce position independent code.  This is not to object against Chris or
> Frank who have done a great job with their gcc ports, I just mention it as
> a little difficulty.

Why would you need position-independant code?

> And what about SLB?  I still haven't understood the concept of them
> entirely, maybe somebody can help me.  Is it true that they don't
> distinguish between text and data, i. e. that they share both?  If this is

Yes.

> the case I doubt very much that you can develop a shared libc based on the
> SLB concept, at least not with the MiNTLib.  I also heard that an SLB

Please explain the relevance of this.

> mustn't "internally allocate" memory.  Is this true?  IMHO it is a feature
> of any library if it allocates memory dynamically instead of using
> fixed-size data structures.

The SLB can allocate memory on instantiation. It also can use Malloc() on
behalf of the calling process.