[MiNT] shared libs

[Guido Flohr <gufl0000@stud.uni-sb.de>]

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.

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
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
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.

I don't mean to flame against SLBs, I just don't know them.  Can somebody
help me? Yes, I know that there is a web-page or something like that about
SLBs.  But I almost never browse the web ...

> > library providing a simple single-file text editor, a library for
> > processing config files, a library for anything else. The point is, that
> 
> Again, libc is absolutely necessary. Does anybody here want to port/write
> something like this?? I don't ;-)

There are at least two open-source and commonly-used toolkits: Qt and gtk.
Both are independent of the native graphics system and both are huge and
slow bastards.  We can't do much for the performance, and for memory
usage, yes, we need shared libraries plus some kind of virtual memory
management with swapping facilities in order to use them.  Unfortunately
AES/VDI don't seem to be powerful enough to support more than a subset of
the features of these toolkits.  They would probably have to be extended
in some way.

Furthermore, none of these dreams could become true on a bare m68000
box ...

Ciao

Guido
-- 
http://stud.uni-sb.de/~gufl0000/
mailto:guido@freemint.de