program/tool from "FOO" to "TOOL_FOO". The new variables are:
TOOL_ASN1_COMPILE TOOL_CAP_MKDB TOOL_CAT TOOL_CKSUM TOOL_COMPILE_ET
TOOL_CONFIG TOOL_CRUNCHGEN TOOL_CTAGS TOOL_DB TOOL_EQN TOOL_FGEN
TOOL_GENCAT TOOL_GROFF TOOL_HEXDUMP TOOL_INDXBIB TOOL_INSTALLBOOT
TOOL_INSTALL_INFO TOOL_M4 TOOL_MAKEFS TOOL_MAKEINFO TOOL_MAKEWHATIS
TOOL_MDSETIMAGE TOOL_MENUC TOOL_MKCSMAPPER TOOL_MKESDB
TOOL_MKLOCALE TOOL_MKMAGIC TOOL_MKTEMP TOOL_MSGC TOOL_MTREE
TOOL_PAX TOOL_PIC TOOL_PREPMKBOOTIMAGE TOOL_PWD_MKDB TOOL_REFER
TOOL_ROFF_ASCII TOOL_ROFF_DVI TOOL_ROFF_HTML TOOL_ROFF_PS
TOOL_ROFF_RAW TOOL_RPCGEN TOOL_SOELIM TOOL_SUNLABEL TOOL_TBL
TOOL_UUDECODE TOOL_VGRIND TOOL_ZIC
For each, provide default in <bsd.sys.mk> of the form:
TOOL_FOO?= foo
and for the ${USETOOLS}=="yes" case in <bsd.own.mk>, provide override:
TOOL_FOO= ${TOOLDIR}/bin/${_TOOL_PREFIX}foo
Document all of these in bsd.README.
This cleans up a chunk of potential (and actual) namespace collision
within our build infrastructure, as well as improves consistency in
the share/mk documentation and provision of appropriate defaults for
each of these variables.
(g)cc has all the knowledge which startfiles/libgcc to
use, so we don't need to duplicate all that here.
Externally visible change:
Shared objects are linked against libgcc_pic.a now
(if the in-tree gcc2 is used). This fixes problems with
dlopen()'ed objects referencing libgcc functions not used
(thus not linked in) by the main program.
the environment:
CPUFLAGS Additional flags to the compiler/assembler to select
CPU instruction set options, CPU tuning options, etc.
Since CPUFLAGS is not implicitly set by any part of the make infrastructure,
it is safe to set in mk.conf, unlike COPTS or DBG.
* Unnecessarily causes lib/librpcsvc (etc) to be rebuilt every time
rpcgen is updated.
* No other "generated" file (.l, .y, ...) depends upon its tool
like this
* As <bsd.own.mk> wasn't being pulled in, the tools/ version
wasn't being used, so a lot of times the dependency was wrong.
Fixes [toolchain/11568] by Bernd Ernesti.
Note: this is the first tool using a "TOOL_" prefix in the make(1) variable;
other similar "non-standard" variable names will be converted in the future.
cd ${KERNSRCDIR}/${KERNARCHDIR}/compile && ${PRINTOBJDIR}
This is far simpler than the previous system, and more robust with
objdirs built via BSDOBJDIR.
The previous method of finding KERNOBJDIR when using BSDOBJDIR by
referencing _SRC_TOP_OBJ_ from another directory was extremely
fragile due to the depth first tree walk by <bsd.subdir.mk>, and
the caching of _SRC_TOP_OBJ_ (with MAKEOVERRIDES) which would be
empty on the *first* pass to create fresh objdirs.
This change requires adding sys/arch/*/compile/Makefile to create
the objdir in that directory, and descending into arch/*/compile
from arch/*/Makefile. Remove the now-unnecessary .keep_me files
whilst here.
Per lengthy discussion with Andrew Brown.
- add '-D ${DESTDIR}' to INSTPRIV, so install(8) removes the leading
${DESTDIR} from the metalogged path
- provide ${METADB.add} variable (for "${CAT} -l >> ${METALOG}"), to make
it easier to replace manual metalog manipulation in the future.
- with manual metalog additions, don't add the leading ${DESTDIR} in the path
- in maketars, use "mtree -C ..." instead of
"mtree -D ... | sed -e 's,\(.*\) \(\..*\),\2 \1,";
Benefits:
- maketars "Parsing METALOG" step speeds up from 29 seconds to 1.2 seconds
on a P3-600.
(This also benefits "make installworld" at the top level.)
- ${DESTDIR}/METALOG is easier to read without the leading "${DESTDIR}"
on all the pathnames, and it's smaller as well.
Fixes a problem found by Andrew Brown where programs outside of the NetBSD
src that use the /usr/share/mk framework (such as pkgsrc/pkgtools/digest)
couldn't be installed if /usr/src/etc wasn't present.
rules use that directory to lookup users & groups as opposed to the
host system's passwd(5) and group(5) databases.
This is a change of behaviour which should make the build system more
robust when new users & groups are added to the NetBSD source.
The only users who may be adversely affected are those (small number,
if any) that renumber the uids & gids away from the "standard" NetBSD
ones; in this case said users should maintain local mods to
${NETBSDSRCDIR}/etc/{master.passwd,group} ...
things like the .note.netbsd.ident section are provided by crti/crtn.
crti/crtn also provide the _init() and _fini() routines.
crtbegin/crtend now only provide support for ctors/dtors. This paves
the way to using the "crtstuff" provided with GCC (when we upgrade to
GCC 3.3), which provides, among other things, much better C++/Java
exception handling.
and the sources now use that define, so there is no need for us to define
ABICALLS. Since that was the only use for the AINC variable, garbage-collect
it.
-dynamic-linker=/libexec/ld.elf_so) if the BINDIR of the program being
built is /bin or /sbin.
The reason we do this is because now all programs *except* those in
/bin and /sbin (i.e. the "special cases") match the default the compiler
uses, which is what is used for things in e.g. xsrc, pkgsrc, and other
random 3rd party programs.
This is done by decoupling where a shlib is installed from how it
is located. Two new variables, SHLIBINSTALLDIR and SHLINKINSTALLDIR,
contain the former information, and key off MKDYNAMICROOT only. SHLIBDIR
and SHLINKDIR contain the latter, and key off MKDYNAMICROOT and BINDIR.
The SHLIBINSTALLDIR, SHLIBDIR, _LIBSODIR, SHLINKINSTALLDIR, and
SHLINKDIR parameters are moved to a new <bsd.shlib.mk>; see bsd.README
for usage details.
-dynamic-linker=/libexec/ld.elf_so) if the BINDIR of the program being
built is /bin or /sbin.
The reason we do this is because now all programs *except* those in
/bin and /sbin (i.e. the "special cases") match the default the compiler
uses, which is what is used for things in e.g. xsrc, pkgsrc, and other
random 3rd party programs.
This means that:
+ /bin and /sbin (and the few programs in /usr/* which were statically
linked) are now dynamically linked.
+ The shared libraries that are needed by the /bin and /sbin programs
are now installed into /lib (with compatability symlinks from
/usr/lib). These are:
c crypt edit ipsec kvm m m387 termcap termlib util z
+ The shared linker is now in /libexec/ld.elf_so, and
/usr/libexec/ld.elf_so is a symlink to the former.
If you want the prior behaviour of "some applications statically linked,
the rest dynamically linked", set MKDYNAMICROOT=no in your mk.conf(5).
If you have a philosophical objection to dynamic libraries, continue
to set LDSTATIC=-static in your mk.conf(5), and please don't waste any
more time in trying to convince us why dynamic libraries are 3v1l.
two variables:
TOOLCHAIN_MISSING -- set to "yes" on platforms for which there is
no working in-tree toolchain (hppa, ns32k, sh5, x86_64).
EXTERNAL_TOOLCHAIN -- if defined by the user, points to the root of
an external toolchain (e.g. /usr/local/gnu). This enables the cross-build
framework even for TOOLCHAIN_MISSING platforms.
If TOOLCHAIN_MISSING is set to "yes", MKGDB, MKBFD, and MKGCC are all
unconditionally set to "no", since the bits are not there to build.
If EXTERNAL_TOOLCHAIN is set, MKGCC is unconditionally set to "no",
since the external toolchain's compiler is not in-sync with the
in-tree compiler support components (e.g. libgcc).
* Set MACHINE_CPU much earlier in bsd.own.mk, so that more tests in
that file can use it.
be changed in the future to "yes".
If MKDYNAMICROOT == "no", there is no change from existing behaviour
of a static /bin and /sbin (and a few programs in elsewhere).
If MKDYNAMICROOT == "yes", the following changes occur:
in <bsd.own.mk>:
SHLIBDIR?= /lib
SHLINKDIR?= /lib
in various Makefiles, the following entry is DISABLED.
LDSTATIC?=-static
This results in all programs (except those "standalone" programs built
in sys/arch/*/stand) are linked dynamically, the shared linker is moved
from /usr/libexec to /lib (with a compat symlink), and the shared
libraries used by /bin and /sbin programs are moved from /usr/lib to
/lib (with compat symlinks).
as they default to using install(1) -r.
the rm can cause problems in certain situations, such as moving a library or
shared linker that install(1) depends upon to another location and replacing
it with a (sym)link.
* Don't make OBJECT_FMT dependent on USE_NEW_TOOLCHAIN. All ports
except ns32k are ELF, so set it appropriately. Allow it to be
overridden in the ns32k case.
* If ns32k && USE_NEW_TOOLCHAIN, don't build shared libraries, because
external toolchains don't support them for our a.out.
* If ns32k && OBJECT_FMT == ELF, the GNU platform is "netbsdelf".
* If ns32k && USE_NEW_TOOLCHAIN, don't attempt to build the in-tree
binutils 2.11.2, gdb 5.0, or gcc 2.95.3.
This allows us to do USE_NEW_TOOLCHAIN cross-builds to ns32k using
an external toolchain.
There were too many synchronisation problems with using the former;
including situations such as a "make clean" performed between two
installs to the same DESTDIR would result in a truncated METALOG and
the resultant sets would be missing stuff such as include files that
don't get reinstalled if they haven't changed, even with !UPDATE.
Sources for a target do not accumulate over dependency lines
when this operator is used.
An unstated implication of this is that when parallel builds are done,
each separate instance of the target can be scheduled independantly.
As a result, the linksinstall target with commands could be executed
too early during a parallel build since they didn't actually have a
dependancy on "realinstall".
To fix this, correct the linksinstall:: realinstall dependancy by
eliminating the command-less linksinstall target, and moving the
dependancy to the other linksinstall target.
Defaults to the directory determined by the _SRC_TOP_ logic (if != ""),
and the BSDSRCDIR.
NETBSDSRCDIR has been provided for use by the various NetBSD source
Makefiles to find the top of the NetBSD source tree, and isn't
affected by the inheritance properties of _SRC_TOP_, nor does it
have the magic BSDOBJDIR baggage that BSDSRCDIR is stuck with.
determined, since BSDSRCDIR's default of /usr/src might not exist and the
calculation of _SRC_TOP_OBJ_ would then generate a warning :-(.
_SRC_TOP_ can now == "" if make(1) (or a parent make(1)) was started
outside of the NetBSD source tree.
Now, if _SRC_TOP_ != "", BSDSRCDIR defaults to ${_SRC_TOP_} and
BSDOBJDIR defaults to the objdir of ${BSDSRCDIR}.
Failsafe defaults for BSDSRCDIR (/usr/src) and BSDOBJDIR (/usr/obj)
are provided later in the file.
This should result in a usable BSDSRCDIR default (i.e, _SRC_TOP_ if
running from within the source tree), with safe fallbacks as appropriate
(/usr/src, as always), meaning that BSDSRCDIR should be able to be used
instead of _SRC_TOP_ in the source tree, although I need to carefully
test this. *aaaiiiieeee!!!*. (Now I understand some of Todd's pain :)
make -V FILES
from being useful (and given that every other variable can be
extracted using make -V, the behaviour was unusually inconsistent
given that the original reason for clearing it doesn't seem to be
relevant anymore)
- use <bsd.prog.mk> instead of directly including <bsd.files.mk>
(and possibly <bsd.man.mk> or <bsd.own.mk>)
- remove obsolete NOPROG
${BSDSRCDIR} if make(1) is running outside of the NetBSD source tree.
This should solve various issues, including building xsrc which uses
${BSDSRCDIR}/distrib/sets/maketars.
infrastructure and using that infrastructure in programs.
* MKHESIOD, MKKERBEROS, MKSKEY, and MKYP control building
of the infratsructure (libraries, support programs, etc.)
* USE_HESIOD, USE_KERBEROS, USE_SKEY, and USE_YP control
building of support for using the corresponding API
in various libraries/programs that can use it.
As discussed on tech-toolchain.
Instead of:
install -m 600 [...]
ranlib -t [...]
chmod 444 [...]
use the newly added "-a" flag to install(1) to invoke ranlib ifndef UPDATE.
Should prevent unnecessary ranlib-ing of installed libraries with UPDATE
defined.
Per discussion with simonb.
round has been tested on Solaris/x86 and Linux hosts.
* Add host tools cap_mkdb, ctags, m4, uudecode.
* Protect __RCSID() and __COPYRIGHT() better.
* Reduce the number of places that need to include "config.h", to keep
sources closer to their "vanilla" versions.
* Add more compat #defines and autoconf-checked functions.
compiles. Based loosely on mkdep.old.compiler (so CSRG license copied),
but now uses just one rewrite (awk) process per cpp invocation and
determines the proper way to run cpp and awk via a "configure" script.
Use HOST_MKDEP in bsd.hostlib/hostprog.mk (defaulting to the old override
value of MKDEP), and give it a TOOLDIR equivalent in bsd.own.mk.
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?
