On Fri, Jan 26, 2007 at 10:51:02PM -0800, Romit wrote:
> I am trying desperately to build a kernel from the opensolaris
> code base. I could see that the opensolaris.sh file has incorrect
> options for the NIGHTLY_OPTIONS shell variable
> NIGHTLY_OPTIONS="-FNnaCDlmrt"; export NIGHTLY_OPTIONS
>
> Look at the option 't'
> In th bldenv.sh program it sets up other build related variables if
> this option is set. I can see that ONBLD_TOOLS is set to
> ${SRC}/tools/proto/opt/onbld tools if this is set. But we are
> advised to put the onbld tools under /opt in the README.
>
> So I removed the 't' option from the NIGHTLY_OPTIONS variable. Now
The use of -t is not incorrect. This option causes the build tools
found in usr/src/tools to be built at the beginning of the build and
then used to build the remaining source. That is, it's a tools
bootstrap flag. This is useful because it allows you to continue
building across (some) kinds of changes to the tools without forcing
you to download and install a new SUNWonbld package every day.
You still need the build tools installed, preferably in /opt/onbld
(the default package install location), and you still need to have the
compilers installed there as well for a default build.
> /opt/onbld/bin/i386/ctfconvert -i -L VERSION debug64/cbe.o
> *** Error code 1
> The following command caused the error:
> BUILD_TYPE=DBG64 VERSION='onnv-gate' dmake install.targ
This is not enough information to know what went wrong; you will need
to look through nightly.log and grep for these error messages, then
see what precedes them. However, I doubt it's worth doing since your
removal of the -t option triggered it. Most likely you should do the
following and then try your build again:
- Download and install the latest SUNWonbld package for your architecture
- Restore the 't' option in your environment file
If after taking those actions, your build still fails, please send the
output from nightly.log that shows the actual command that failed and
its output. Normally the mail message does not contain this.
> Also, I would suggest that before publishing the source if some
> sanity test is done, then it saves a lot of time.
The biweekly builds are generally tested and known to build and at
least work to some degree. Source available via the SCM repository
mirrors is updated automatically and may occasionally fail to build
due to SCM bridging issues and/or (very rarely) brokenness in the
source itself. It's also much more likely to fail to build if your
tools are out of date, especially if you unwisely remove the 't'
option.
You can find out more about nightly and the rest of the build process
at http://www.opensolaris.org/os/community/on/devref_toc/ and in the
nightly(1) man page (try man -M /opt/onbld/man nightly). You should
also check the flag day notices appropriate to the source you're
trying to build at (for example)
http://www.opensolaris.org/os/community/on/flag-days/56-60/; these
will tell you when new tools are required, when Install will not work,
and other important information. Most build failures are caused by
old tools and/or missed flag days.
--
Keith M Wesolowski "Sir, we're surrounded!"
FishWorks "Excellent; we can attack in any direction!"
_______________________________________________
opensolaris-code mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
