Don't know if anyone is reading this, but...

Excuse me for not checking NetBSD-current first.  It pays to do that.

It looks like the new Makefile for ld.so may address this problem.  If
so, someone was exactly 2 weeks ahead of me.  I haven't had time to try
it yet, so I can't say for certain, not being a make language guru.
 
This looks like another empty chamber, but I'll post the outcome
anyway...if I ever find that shaft of sunlight again...

I'm _still_ wondering how the sucker ever got built to begin with.


--Jim Howard  <jiho@mail.c-zone.net>


On 03-Jun-98 some passerby wrote:

> I'd guess this would be at least the second inquiry on this point.
>
> How does ld.so (the runtime linker, source tree
> /usr/src/gnu/usr.bin/ld/rtld) get built without a conflict between
> its built-in malloc functions and those in libc_pic.a?
>
> Trying to build ld.so in isolation, the only way I've succeeded is
> to build a special libc_pic.a without malloc functions, and refer to
> that locally for the ld.so build!  Otherwise, ld complains about
> multiple definitions for the malloc functions and aborts the link.
>
> I gather this has to do with the -Bsymbolic option, which must be
> used.  But how is this nifty little conundrum avoided, to build
> ld.so for the distributions?!?
>
> I did rebuild the C library previously -- to put an alternative
> malloc in it, ironically enough.  It works fine, of course.  But I
> didn't tamper with the build procedure for that, and I struggle to
> imagine how that could impact this, even if I had....
>
> I'm running 1.2/i386.
>
> Thanks.
>
>
> --Jim Howard  <jiho@mail.c-zone.net>


----------------------------------
E-Mail: jiho@mail.c-zone.net
Date: 04-Jun-98
Time: 18:06:09

This message was sent by XFMail
----------------------------------