Alan Hargreaves' Blog

The ramblings of an Australian SaND TSC* Principal Field Technologist

Non-Debug OpenSolaris – Build 49 (with added BrandZ)

In the light of a response from Bonnie Corwin to a question I asked in a thread on the coders alias, it looks like I have some work to do.

OK, if it’s ok for me to make such things available under the stated conditions, where should I start?

Given that BrandZ integrated the other day and that Steve has done a code drop with this in, that’s probably not a bad starting point.

The only thing that I need to be careful of is that I don’t want to touch the source tree that I am keeping the formal builds synced up with.

You have to love ZFS. I currently have this tree as it’s own ZFS filesystem and have been taking snapshots just before I do a resync. It’s currently at b47 and I’ll be doing b48 shortly. Now, how to work with this tree and the nightly clones that Steve built the current code drop from?

Bring in the clones.

It was just a matter of taking another snapshot and generating a clone against it. Actually I could have chosen any of my existing snapshots, but I am being extra careful here (this is actually my first attempt at playing with clones and I’m impressed).

# zfs snapshot export/onnv-ndbits@nightly
# zfs clone export/onnv-ndbits@nightly export/build/onnv-ndbits49

I now have a source tree that I can sync up with the build 49 clone from last night.

That’s all done, now I just need to do a local bringover of it, tar it up and drop it onto my build machine.

Oops, not quite. The build machine doen’t have the new compilers.

OK they’ve been updated. As I need a new onbld due to the compiler change and I need the new stuff for doing the combined builds. I have to build a new SUNWonbld.

That done and installed, I’ve kicked off the build. Let’s see how long it takes a v40z to build two sets of encumbered binary tarballs.

Once I got things on the machine sorted out (and remembered to use dmake) it took about two hours.

For the moment, I’m uploading this to mediacast rather than put it up on dlc (although I’ll get there). The file is on-closed-bins-nd-20060911.i386.tar.bz2

Now, let’s get it going on my notebook.

First off, as the tarball extracts into root_i386-nd. This is not going to build out of the box. In my tree I’ve made a modification to usr/src/Makefile to work with this. You have two choices on how to procees.

  • Rename closed/root_i386-nd to closed/root_i386

  • Make a minor change to usr/src/Makefile where it copies the tarball into ${ROOT}.

    ------- usr/src/Makefile -------
    Index: usr/src/Makefile
    --- /export/build/nd/tonic.20060911/usr/src/Makefile    Wed Sep 13 10:06:42 2006
    +++ /export/build/nd/onnv-ndbits49/usr/src/Makefile     Wed Sep 13 12:10:40 2006
    @@ -117,14 +117,15 @@
    @cd lib; pwd; $(MAKE) install
    closedbins: FRC $(ROOTDIRS)
    -       @if [ "$$CLOSED_IS_PRESENT" = no ]; then \
    -               if [ ! -d "$$ON_CLOSED_BINS/root_$(MACH)" ]; then \
    +       @CLOSED_ROOT="$$ON_CLOSED_BINS/root_$(MACH)$${RELEASE_BUILD+-nd}"; \
    +       if [ "$$CLOSED_IS_PRESENT" = no ]; then \
    +               if [ ! -d "$$CLOSED_ROOT" ]; then \
    $(ECHO) "Error: if closed sources are not present," \
    "ON_CLOSED_BINS must point to closed binaries."; \
    exit 1; \
    fi; \
    $(ECHO) "Copying closed binaries from $$ON_CLOSED_BINS"; \
    -               (cd $$ON_CLOSED_BINS/root_$(MACH); tar cf - .) | \
    +               (cd $$CLOSED_ROOT; tar cf - .) | \
    (cd $(ROOT); tar xBf -); \

    All this does is to tell the Makefile that the closed root has the “-nd” suffix if ${RELEASE_BUILD} is set, which will be the case for a non-debug build.

The way that the encumbered binaries are handled is that at the beginning of the make, they are copied into the proto area. It currently assumes that the closed bins contains only root_${ARCH}.

Once that is done, you need to modify the NIGHTLY_FLAGS in such that you ony get a non-debug build. Simply removed the D and F options.

Now it’s just a case of kicking off the nightly build and waiting, then doing a bfu.

As you can see I’ve got a version built and running on my ferrari 4005.

Sun Microsystems Inc.   SunOS 5.11      opensolaris49-nd        October 2007
bfu'ed from /export/build/opensolaris49/archives/i386/nightly-nd on 2006-09-14
Sun Microsystems Inc.   SunOS 5.11      snv_47  October 2007
You have mail.
$ uname -a
SunOS red 5.11 opensolaris49-nd i86pc i386 i86pc

I’ll get an lx Branded Zone up and running in the next day or so, remembering that there are a few other things I’ll need to do like updating the package tools.

I’ve not had a lot of chance to test this stuff and I’d really appreciate feedback while we’re reviewing the code changes needed to build this stuff. Once I have more confidence in them I’ll start posting them with Steve’s code drops.

On a quasi legal note, these binaries are distributed under exactly the same license as the debug encumbered binaries (that was a requirement of me making them available).

Technorati Tags:


Written by Alan

September 14, 2006 at 2:15 am

Posted in OpenSolaris

One Response

Subscribe to comments with RSS.

  1. This is awesome news for the OpenSolaris community. This means that we no longer have to build “just debug” or “almost entirely non-debug” — thank you! I can now run updated production OpenSolaris on my system without updating my SCXR all the time.

    Michael Hayes

    September 14, 2006 at 7:30 pm

Comments are closed.

%d bloggers like this: