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