old one either. The "new toolchain" environment is closer to what we
want, however, for using the external toolchain currently required for
x86_64, so set USE_NEW_TOOLCHAIN for x86_64.
- SHLIBDIR Location to install shared libraries if ${USE_SHLIBDIR}
is "yes". Defaults to "/usr/lib".
- USE_SHLIBDIR If "yes", install shared libraries in ${SHLIBDIR}
instead of ${LIBDIR}. Defaults to "no".
Sets ${_LIBSODIR} to the appropriate value.
This may be set by individual Makefiles as well.
- SHLINKDIR Location of shared linker. Defaults to "/usr/libexec".
If != "/usr/libexec", change the dynamic-linker
encoded in shared programs
* Set USE_SHLIBDIR for libraries used by /bin and /sbin:
libc libcrypt libcrypto libedit libipsec libkvm libm libmi387
libtermcap libutil libz
* If ${_LIBSODIR} != ${LIBDIR}, add symlinks from ${LIBDIR}/${LIB}.so*
to ${_LIBSODIR}/${LIB}.so* for compatibility.
* Always install /sbin/init statically (for now)
The net effect of these changes depends on how the variables are set:
1.) If nothing is set or changed, there is no change from the
current behaviour:
- Static /bin, /sbin, and bits of /usr/*
- Dynamic rest
- Shared linker is /usr/libexec/ld*so
2.) If the following make variables are set:
LDSTATIC=
SHLINKDIR=/lib
SHLIBDIR=/lib
Then the behaviour becomes:
- Dynamic tools
- .so libraries used by /bin and /sbin are installed to /lib,
with symlinks from /usr/lib/lib*so to -> /lib/lib*so
where appropriate
- Shared linker is /lib/ld*so
3.) As per 2.), but add the following variable:
USE_SHLIBDIR=yes
This forces all .so's to be instaleld in /lib (with compat
symlinks), not just those tagged by their Makefiles to be.
Again, compat symlinks are installed
it (kernel and libc).
The current version of the gas assembler in the tree (2.11.2) already
defaults to generating object files for "-Av9 -64", supporting V9
instructions in ELF64 object format. "-Av9a" is only needed for specific
parts of the NetBSD base sources, and not for all third-party code.
Wrap assignments of various tools within USETOOLS_BINUTILS and
USETOOLS_GCC (names reflect the FSF packages the tools are provided
by), which default to "yes", for easy testing of different versions
of these packages.
can be specified in mk.conf: AR, AS, LD, NM, OBJCOPY, OBJDUMP,
RANLIB, SIZE, and STRIP.
This, along with some symlinks in TOOLDIR, makes it much easier to
test different versions of the GNU toolchain (e.g. binutils-current).
as it calls troff/etc without any leading pathnames. Otherwise the tools
version is fairly useless as the installed system version will be used to
build all manpages
The dependency should be against the TOOLDIR files (is USETOOLS=yes) but
installs will always use ${DESTDIR}/usr/share/tmac.
Without this if people do not have /usr/share/tmac/tmac.andoc on their
systems while building the build will break in the groff areas due to
the dependency rules.
i.e. if the root of the object tree doesn't exist then complain and exit.
This makes both sections consistant to each other (MAKEOBJDIR specifies an
exact directory so there's no root per se to check so nothing can really be
done there).
Use the old setup for MAKEOBJDIRPREFIX but also add a new check for
_SRC_TOP_OBJ_ and use that if it's set. This allows a make release using
build.sh (which uses MAKEOBJDIR patterns) to function correctly on r/o
source tree's.
INSTALL_FILE does.
2) Patch around a bug that has been biting people in which bsd.own.mk
attempts to cd into space when building outside of the tree. I may
have a better solution for the whole thing later.
make bsd.lib.mk use INSTALL_SYMLINK instead of mv and ln -s.
Note: There is still one weird case I left alone, in which symlinks
get built in the objdir. I didn't want to log metadata for those links
so I left the old machinery in for them.
XXX do we even need that elaborate dance for the ln's in the objdir?
