under way to move the remnants of the a.out toolchain to ports. As the
comment in src/Makefile said, this stuff is deprecated and one should not
expect this to remain beyond 4.0-REL. It has already lasted WAY beyond
that.
Notable exceptions:
gcc - I have not touched the a.out generation stuff there.
ldd/ldconfig - still have some code to interface with a.out rtld.
old as/ld/etc - I have not removed these yet, pending their move to ports.
some includes - necessary for ldd/ldconfig for now.
Tested on: i386 (extensively), alpha
the environment for the last command of the pipeline (xargs) instead
of too early in the broken version or using an extra env process for
each command spawned by xargs as in rev.1.12. Fixed a nearby English
error.
-finstrument-functions instead of -mprofiler-epilogue. The former
works essentially the same as the latter but has a higher overhead
(about 22 more bytes per function for passing unused args to the
profiling functions).
Removed all traces of the IDENT Makefile variable, which had been
reduced to just a place for holding profiling's contribution to CFLAGS
(the IDENT that gives the kernel identity was renamed to KERN_IDENT).
to build kernel and kernel modules so stop supporting them in
bsd.subdir.mk and reimplement them in kern.post.mk and kmod.mk
as special versions of the install and reinstall targets, and
only define them if DEBUG is also defined (when debug versions
are really built).
Prompted by: bde
"env name=value ... cmd ..." is just a pessimized way of doing
"name=value ... cmd ..." in real shells. Set the environment
(without using env(1)) before starting xargs so that env(1)
is not needed in "xargs env name=value ... cmd ..."
lint, so this is turned off by default. Setting WANT_LINT will turn
on generation of lint libraries for /usr/libdata/lint/*.ln.
Reviewd by: silence in -audit.
so that this is safe even if VARIABLE is longer than kern.argmax.
There is another instance of CFILES which might need the same treatment,
and might be noticed when doing a "make links".
The same has to be done in RELENG_4 (on some different file).
Noticed-by: picobsd cross-compiling LINT
Suggested-by: Alfred (bright@mu.org), des@freebsd.org
MFC-after: 3 days
simplifying the module linking process and eliminating the risks
associated with doubly-defined variables.
Cases where commons were legitimately used (detection of
compiled-in subsystems) have been converted to use sysinits, and
any new code should use this or an equivalent practice as a
matter of course.
Modules can override this behaviour by substituting -fno-common
out of ${CFLAGS} in cases where commons are necessary
(eg. third-party object modules). Commons will be resolved and
allocated space when the kld is linked as part of the module
build process, so they will not pose a risk to the kernel or
other modules.
Provide a mechanism for controlling the export of symbols from
the module namespace. The EXPORT_SYMS variable may be set in the
Makefile to NO (export no symbols), a list of symbols to export,
or the name of a file containing a newline-seperated list of
symbols to be exported. Non-exported symbols are converted to
local symbols. If EXPORT_SYMS is not set, all global symbols are
currently exported. This behaviour is expected to change (to
exporting no symbols) once modules have been converted.
Reviewed by: peter (in principle)
Obtained from: green (kmod_syms.awk)
kern.post.mk.
# this should allow us to move kern.post.mk to the last line of the makefiles,
# but I'll do that slowly as I verify that one can do that w/o breaking things.
Submitted by: naddy
Fix it by putting back the link of machine to sys/i386/include rather
than ../../include (aka sys/pc98/include). I had a stale machine link
on my first test.
Not sure what the "right" fix is, but this unbreaks things.
new files: kern.pre.mk, which contains most of the definitions, and
kern.post.mk, which contains most of the rules.
I've tested this on i386 and pc98. I have had feedback on the sparc64
port, but no reports from anybody on alpha, ia64 or powerpc. I
appologize in advance if I've broken you.
Reviewed by: jake, jhb, arch@
