> bsd.lib.mk contains alpha specific commands for building shared
> libraries which reference objects previously installed in /usr/lib.

Yup.


> The 'make build' commands in /usr/src/Makefile expect to be able
> to update /usr/src/lib in one pass. This means that shared libraries
> will always be linked against the crtbeginS.o and crtendS.o objects
> built previously -- never the latest ones.

yup.  I've pointed out time and time again that the NetBSD build
process, esp. w.r.t. the "DESTDIR" install garbage is fatally flawed.


> Looking at the *.mk files, this is the _only_ occurrence of a hard
> coded path to an object that is used to build something else. All
> other paths are where things are put and they are all relative
> to DESTDIR. I think it would be a shame to allow this sort of
> design propagate.

the entire DESTDIR design is broken, and i'll describe why below.


> I'd like to see this design change so that builds of /usr/src/lib use the
> objects built in ${DESTDIR}/lib/csu/alpha and other builds use the
> objects installed by the build of /usr/src/lib.

The objects built _where_?  objects ARE NOT built into DESTDIR,
objects are installed into destdir.

This means that if you do something like:

	make lib
		-> make csu
		-> make libc
		-> etc.

	install lib
		-> install csu
		-> install libc
		-> etc.

The 'make libc' and subsequent library steps _CANNOT_ require
other library 'installed objects' (e.g. the csu .o files), because
they won't have been installed in DESTDIR (or anywhere else for that
matter) until the install is done.

You can't reasonably use ${OBJDIR}, because the user might have done
something which causes it to fall over, ranging from the simple (and
relatively easy to handle) case of having vs. not having an obj
directory in the csu subdir, to having objdirs with machine postfixes,
or having some be symlinks into an obj tree and others real
directories.


The right solution to this problem is to have a 'build tree' from
which binaries can be used while building.  E.g. when you build a
library, it not only builds the .o's and .a's, but also places the
.a's, exported headers, etc., in a place that's easily accessible to
other parts of the build process.  That's currently not done with
(quite conceptually broken) DESTDIR scheme, causing the DESTDIR scheme
to require that libraries be 'install'ed before they are used.  (Note
that 'make build' does an install of the libaries before trying to
build programs from them!)  The closest you could come to 'the right
thing' with the DESTDIR build scheme is to specially build and install
csu before the rest of lib is built.  However, that's at best a hack,
and i _really_ DO NOT want people to become accustomed to using
DESTDIR builds, since they are fatally flawed (as implemented), and
should change significantly.

Curt Sampson was working on a better replacement for the current build
lossage, but I don't know if he ever got anywhere with it.


cgd