| Date Of Receipt: 12-SEP-1995 15:33:12.66
From: SMURF::ALPHA::"vandyck@cardinal.zk3.dec.com" "12-Sep-1995 1530"
To: ahrens@oleum.zso.dec.com
CC: buildhelp@zk3.dec.com
Subj: Re: building w/ linked objects
|
| Please give me the procedure on how to build a kernel
| using linked objects. I just did a "mklinks obj/alpha",
| but I'm sure I made too many links and don't know where
| to begin to debug this. Like I said before, I just
| want to make a FLAMINGO kernel and I just changed
| the kernel/ufs/ufs_vnops.c file. I don't have a clue on
| what objects have the wrong permissions. Please help me
| start from the beginning.
|
| Christine
The following is from the rengweb home page under the getting help section:
Last Updated: 1/11/95
> build BINARY
This does a complete build of the BINARY directory: config, scalls,
depend, and vmunix. The vmunix step includes modules.
> build BINARY_vmunix
This builds all object files in BINARY, and makes all modules.
> build BINARY_ "MAKE_ARGS=objectfile.o"
(or) > build BINARY_objectfile.o
This builds a single object file if it is out of date or missing.
If the environment variable DO_MODULES is set to AUTO, and the
object file is part of a module, that module will be rebuilt.
> build BINARY_ "MAKE_ARGS=MODULE_xxx.o"
This builds a module, after checking for and building the component
object files that go into it.
> build BINARY_ "MAKE_ARGS=MODULE_xxx"
Will just relink the module, without building its component object
files. If one or more is missing, the build fails.
Note: this is different from building MODULE_xxx.o in that it does
not attempt to rebuild the component object files. This rule is useful
on installed systems to just relink a module when a modified source
file is copied onto the system and recompiled:
# cp alpha:/tmp/my_vfs_subr.c /usr/sys/vfs/vfs_subr.c
# cd /usr/sys/BINARY
# make vfs_subr.o
# make MODULE_vfs /* or make MODULES */
Here, an attempt to make MODULE_vfs.o would fail because the source
files for the other objects in the module are not present.
> build BINARY_MODULES
This rule relinks all modules but does *not* rebuild their component
object files. If one or more of these files are missing, the build fails.
This rule is equivalent to building MODULE_xxx for each module.
Notes:
- ------
1: BINARY files no longer have any compile-time dependency on "target"
information, such as the number of controllers/devices, or which platforms
are to be supported.
2: BINARY no longer cares about target OPTIONS. Every source file listed
in conf/files and conf/alpha/files is compiled. Only target configurations
control inclusion of files. Thus, files that do not compile can no longer
be listed in conf/files or conf/alpha/files with their controlling option
turned off.
3: If the environment variable DO_MODULES is set to AUTO, each time a
component object file is rebuilt, the module it belongs to is relinked.
This should only be used when updating object files. Do not use it when
performing a complete build. The build will fail when the first rebuild
of a component file triggers a relink of a module with the other components
not yet built.
--------------------------------------------------------------------------
As part of the ongoing work to modularize the kernel, a change is being
submitted to the way TARGET kernels are built. This change does not affect
the BINARY build at all.
Starting tomorrow, all NOTBINARY files, ORDERED files, and some other
config-generated odds'n'ends (LOBJS: param.o, ioconf.o, conf.o) are now
linked into a single module, named TARGET.o, where <TARGET> is the name
of the configuration (e.g. FLAMINGO, GENERIC, SABLE, etc.). This module
is not explicitly named in the files files, but is implicit in the rules.
This module is the object used to build vmunix, and is listed in the
dependencies for the "vmunix" rule; it in turn depends on each of the
individual object files that build it.
There is only one direct change to the way target kernels are built.
The TARGET.o module is *not* in the dependencies for the "relink" rule.
That is, if a Binary ORDERED file (e.g. scb.o) is rebuilt in BINARY,
the TARGET.o module will *not* be automatically rebuilt with just a
"build TARGET_relink", and the new scb.o will *not* be in the new kernel.
You must do a "build TARGET_TARGET.o" first, or a "build TARGET_vmunix"
to rebuild the TARGET.o module.
Rebuilding TARGET.o will attempt to rebuild all NOTBINARY objects, and
will relink to BINARY files as needed. There is little difference between
"build TARGET_TARGET.o ; build TARGET_relink" and "build TARGET_vmunix".
Currently, there is no rule to just re-link the TARGET.o module as there
is with BINARY modules. It rarely makes a difference if extra NOTBINARY
files are re-compiled. If there is a strong desire for such a rule, I
will consider adding it.
-Grant
|