On Thu, 4 Jan 1996, Jason Thorpe wrote:

> On Thu, 4 Jan 1996 16:16:41 +0000 (GMT) 
>  Thorsten Frueauf <frueauf@ira.uka.de> wrote:
> 
>  > /usr/libexec/ld.so: Undefined symbol "_vlimit" in grep:/usr/lib/libgnumalloc.so.0.0
>  > /usr/libexec/ld.so: Undefined symbol "_vlimit" in gcc:/usr/lib/libgnumalloc.so.0.0
> 
> I recently fixed this.  Here's the commit message to mem-limits.h:
Isn't this a dead-lock? When compiling you need 
/usr/lib/libgnumalloc.so.0.0 to be the old one (e.g. from the 1.1 
release) to be able to execute the compiler and linker, but then you link 
your new software with this same libgnumalloc, which in the end has the effect 
of never being able to upgrade it.

I'm currently trying (in my free time, on a Mac IIcx, over several days) 
to recompile/install my software using a DESTDIR environment variable, 
which I didn't do before. This might cure it, but I don't know yet.


> 
>  #if defined(__bsdi__) && defined(__NetBSD__)

I didn't check the definition of __bsdi__, but I'm tempted to suggest to 
double-check whether to use || or &&.
 > 
> BTW, also make sure you build ld.so with `-fno-function-cse', or you'll 
> really lose on the m68k (trust me...)
I believe you. In fact I did this, and every non-statically-linked program
produced a core dump instead of doing their work. Rather nasty. 
Reinstalling just ld.so from the 1.1 release made the system work again,
and then the libgnumalloc problem popped up while I was trying to 
recompile and install again, so now I just hope that I'll be able to 
catch up again before the next show stopper appears. :-)

regards
Erik Bertelsen.