bind getting stuck?

[Frank Irwin]

In article <1255 at dkunix9.dk.oracle.com> bengsig at dk.oracle.com (Bjorn Engsig) writes:
>Article <1991Feb15.190657.47304 at uvmark.uucp> by irwin at uvmark.uucp (Frank Irwin) says:
>Since libc.a is not much more that one big shared object (ever did ar tv on it?)
>you would expect that you cannot replace a module by another one.  Also, and
>this is important, this is definately not according to ANSI C.  If you don't
>want malloc(), use your_malloc() in stead.

But I also want the system functions to use our malloc().  We've experienced
memory space corruption when our malloc() and the system malloc() are both
used.

>|To do this, I use the -bnoautoimp -berok -bnogc options to ld.  However,
>|bind never seems to complete.
>It is sometimes very time consuming, in particular if you are low on real
>memory.  If you are (also) low on paging you'll get killed by signal 9.

We've got 32MB of real memory, and 128MB paging space.

>The best one is to use your_malloc() all over your code.  That's guaranteed
>to work; but it does of course need to call malloc() eventually to get the
>memory, or you could try to implement it using shared memory calls, which
>is also hard since there is no brk() equivalent on shared memory.

No, our malloc() doesn't call the system malloc().  We use brk() and sbrk()
to get the space, then manage it ourselves.

On machines which don't use shared libraries, this has not given us a 
problem.  Actually, we also have no problems with machines that do have
shared libraries, if they allow us to bind in everything at load time,
as SunOS4.1 does.

-- 
====================================================================
Frank Irwin                   |  "I'll bet $50 on that flush."
Vmark Software, Inc.          |  Whooooosh!
 ..uunet!merk!uvmark!irwin    |  "Aaaaiiiieeee!  Not *that* flush!"