On 05-Jun-98 Castor Fu wrote:

> You know, I asked something similar to this several months ago
> for the mips architecture.  Turned out that people were not
> using the gnu ld.so at all, and that the dynamic linker in common
> use was not in the source tree at all.  This resulted in the
> appropriate code getting dropped into /usr/src/libexec/ld.elf_so.

Well, what you mean is, we haven't been using an ld.so built from the
code in the source tree, but the same code built by some other means.

Meanwhile, the NetBSD-current /usr/src/gnu/usr.bin/ld/rtld/Makefile hack
makes no difference.  It just causes the libc_pic.a in /usr/src/lib/libc
to be used instead of the one in /usr/lib.  The link phase still bombs
out on conflicting definitions for the malloc functions.

So I'm STILL wondering how ld.so gets built for the distribution.  The
source you refer to for MIPS and Alpha looks no different than the
source I've got, except it's for ELF instead of a.out.  I doubt if
yours would actually build using its supplied Makefile, any better than
mine does.

However, the NetBSD-current /usr/src/gnu/usr.bin/ld/rtld/Makefile hack
does suggest a possible way to do this.  It uses a "recursive make" to
get the libc source directory in which to find libc_pic.a.  One could
leverage that hack to either build a different version of libc, or to
build just the files from libc that ld.so needs.  That Makefile could be
a work in progress, in other words, since the hack it has wouldn't be
required just to get the libc source directory.

Of course, not being a make guru, it would take a learning curve for me
to figure out how to implement either scenario.


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


----------------------------------
E-Mail: jiho@mail.c-zone.net
Date: 05-Jun-98
Time: 12:24:26

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