ford@crash.CTS.COM (Michael Ditto) (06/11/87)
About shared text and libraries: On the Amiga, the shared libraries are in the ROM -- they are the equivalent of system calls on UNIX. Stdio and other "libc" routines are still linked in with the executable and therefore exist multiple times, so AmigaDOS and UNIX are very similar in terms of memory usage. It is possible to write your own shared library, but it requires special programming techniques. On UNIX System V release 3, this has been done, and there is a shared version of libc available; the supplied UNIX utilities have been compiled with it. It is not the default because it is not possible to use most debugges on a program using a shared library. -=] Mike "Ford" Ditto [=- ford@crash.CTS.COM
mwm@eris.UUCP (06/12/87)
In article <1206@crash.CTS.COM> ford@crash.CTS.COM (Michael Ditto) writes:
<About shared text and libraries: On the Amiga, the shared libraries are in
<the ROM -- they are the equivalent of system calls on UNIX.
Uh, that's a major oversimplification. It's better to say that the
equivalent of Unix system calls have been implemented as shared
libraries. The difference is that, as shared libraries, you can 1)
replace the library and 2) replace entries in a library. Try replacing
your Unix system calls without relinking the kernel.
<"libc" routines are still linked in with the executable and therefore exist
<multiple times, so AmigaDOS and UNIX are very similar in terms of memory
<usage.
Only in the C environment, where the Amiga has to do some extra work
to provide a Unix-like C environment. If you blow off the
Unix-compatable stuff and etc., AmigaDOS suddenly does much better.
<It is possible to write your own shared library, but it requires
<special programming techniques. On UNIX System V release 3, this has been
<done, and there is a shared version of libc available; the supplied UNIX
<utilities have been compiled with it. It is not the default because it is
<not possible to use most debugges on a program using a shared library.
Last time I looked (last year at the Atlanta Usenix), the SysV
libraries required root privs to install (DCL_SYS_ ... oops, sorry;
had a VMS flashback). This was because the memory allocation for
shared memory for a shared library had to be fixed. Ugh. Give me
AmigaDOS dynamic linking or OS/9 PIC anyday.
<mike
--
How many times do you have to fall Mike Meyer
While people stand there gawking? mwm@berkeley.edu
How many times do you have to fall ucbvax!mwm
Before you end up walking? mwm@ucbjade.BITNETford@crash.CTS.COM (Michael Ditto) (06/13/87)
In article <3934@jade.BERKELEY.EDU> mwm@eris.BERKELEY.EDU (Mike (My watch has windows) Meyer) writes: >Last time I looked (last year at the Atlanta Usenix), the SysV >libraries required root privs to install (DCL_SYS_ ... oops, sorry; >had a VMS flashback). This was because the memory allocation for >shared memory for a shared library had to be fixed. You do not need to be root to create or install a shared library (unless you want to replace, for example, the "libc" shared library; this would be like wanting to replace /bin/sh 8-). You have to specify at link time the pathname of the shared portion of the library. If you want to be able to change this file, you must put it somewhere such that you can have write permission. I'm not sure what you mean about the memory allocation, but there is a limitation in that area -- a given shared library must have a fixed virtual address, and (obviously) no two shared libraries that are used by the SAME process can overlap. This usually means that when you are creating a new shared library you just look at what areas are available and pick one that you like, on the (safe) assumption that all libraries could possibly be used by one program. If you for some reason run out of vertual address space, you can really stop and figure out which libraries will never both be needed by the same program, and make them share addresses. This is, however, crufty and not easily automated (I hate to think about trying to build a Makefile that would do this to install a program). -=] Ford [=- ford@crash.CTS.COM ford%oz@prep.mit.ai.edu
rwhite@nu3b2.UUCP (Robert C. White Jr.) (06/15/87)
In article <1221@crash.CTS.COM>, ford@crash.CTS.COM (Michael Ditto) writes: > This usually means that when you are creating a new > shared library you just look at what areas are available and pick one that > you like, on the (safe) assumption that all libraries could possibly be used > by one program. If you for some reason run out of vertual address space, you > can really stop and figure out which libraries will never both be needed by the > same program, and make them share addresses. This is, however, crufty and not > easily automated (I hate to think about trying to build a Makefile that would > do this to install a program). Don't just pick an area of memory at random, The programmers guide contains a list of memory areas and what type of function libraries should be located in each. If you go through the list you will find that the list is quite extensive. A small degree of care will prevent any overlapping problems. Robert.