Build Instructions

SFW Buildable Source for OpenSolaris

This delivery of SFW buildable source for OpenSolaris consists of a single archive:

• source tarball (sfw-src-b#-DATE.tar.bz2)

General Prerequisites

Building SFW is similar to building the Operating System/Networking (ON) consolidation from source. If you are not familiar with building ON from opensolaris.org, please read the instructions and the detailed documentation before starting your build. You will also need the following shared build/install-time tools:

• compiler: Sun Studio 12 with patches as delivered for ON
• compiler: gcc 3.4.3 with patches as delivered with Solaris Express build 22 or later, or SFW build 22 or later.
• ON build tools package (SUNWonbld-DATE.PLATFORM.tar.bz2) from ON

Unlike ON, SFW does not use BFU or BFU archives. There are no closed binaries; the entire consolidation is Open Source.

You can generally build the SFW consolidation on any Solaris/OpenSolaris distribution two builds older than the SFW sources. For example, to build SFW sources for build 58, your distribution must be compatible with Solaris Express build 56 or later. For build 136, your distribution must be compatible with OpenSolaris build 134 or later. These release notes will always contain information about new or additional build environment requirements that may arise from time to time.

SFW requires the same compilers and support tools as ON. Be sure you have installed a recent SUNWonbld package. Note that, unlike ON, SFW does not contain these build tools, so you must install them in advance rather than relying on nightly's 't' option. In general, your build tools must be no more than 2 builds old. You can obtain the latest SUNWonbld package from the ON download site. The required Studio compilers can be obtained from  the Tools community. You must also have the standard Solaris gcc (from Nevada build 22 or later) installed. Note that compilers other than these specific versions have not been tested and may fail to build SFW correctly.

When building on OpenSolaris, which we now do, you need to run 'pkg install redistributable' to get everything. You may also need to run:

        /usr/share/sgml/docbook/docbook-catalog-install.sh

or you will get various "I/O error : Attempt to load network entity" failures  (this seems to still be needed as of 134).  There may be a new service to do this around 141 or so but I still run it myself after every image-update.

The buildable source may contain source for high key-strength crypto. Please note that certain countries restrict the redistribution of high key-strength crypto. If you live in one of these countries, it is your responsibility to ensure that you are complying with your country's laws in this area.

Special Requirements

 Up to build 103: Use Studio 11 compilers for SFW starting with build 49. These are the same compilers used for ON starting with build 48.

 Starting with build 104, Use Studio 12.

Known Issues

• Fixes do not always take into account that they should link against the proto area first, so you may need to have certain bits installed on the build machine to build. This is a good reason to be running bits very close to what you are building.

• Building SFW on a machine which has the Companion installed in /opt/sfw is not recommended. The SFW build uses "configure" which may find things in /opt/sfw. A known incident is that the apache2 build found /opt/sfw/bin/gsed and the resulting SUNWapch2r package required /opt/sfw/bin/gsed. Note that this also applies to other well-known locations like /usr/local.

• The package builds may fail on large ZFS file systems (6459131 and 6558284).

• If you are building x86 binaries, you must use a 64-bit build machine running the 64 bit kernel (6401063).

• Incremental builds may or may not work, as they are not tested as often and may fail trying to overwrite files in the proto area that have scrict permissions. Work was done in build 112 to address this via bugid 6765731, but subsequent changes may at least temporarily cause trouble and there are also concerns in the bug about incrementals as well.

• The build might fail if your umask is not 022. This can manifest as execute permission being stripped from files by teamware, or permissions becoming wrong in the proto area (missing chmods). Note also that a strict umask can affect sccs/teamware and make it hard for others to look at your workspace or even temporarily break the gate.

• If builds by hand work, but nightly seems to think there's an error even though make didn't fail, see if there's some form of the string 'error:' in the build output. nightly detects build failure by looking for that (as it uses 'make -k' to try to catch any errors introduced by separate putbacks) so you may have to filter non-error messages that contain that out. Be very specific in what you filter out, we don't want to miss anything.

• If you have a strange failure from msgmerge, perhaps like this:

/usr/bin/msgmerge: error while opening "scalab.sfbay.sun.com.pot" for reading: No such file or directory

    check and see if the filename is related to something in the environment. For example, 'scalab.sfbay.sun.com.pot' is
    quite interesting as the NIS domain that machine is in is 'scalab.sfbay.sun.com'. So perhaps you have that in your
    environment in a variable like DOMAIN.

• samba fails to build on 145+. this may require a flag day to move to 145+ (it did, to 147).

     This might let you build:

     rm -f usr/src/cmd/samba/Patches/lib-interfaces.c.diff
     rm -f usr/src/cmd/samba/Patches/lib-replace-test-getifaddrs.c.diff

     (though make/sccs might bring them back so you may need to teamware delete them)

     and there is more. It's in:

6978506 sfw doesn't build on 145+

• we fail to build on 137 until

6944247 getifaddrs in 137 breaks sfw build

     is fixed.

• In build 136 and 137, a 64 bit version of wxwidgets will fail to build due to

6941308   64 bit libXcursor.so is missing in build 136

• If you get a failure like this:

==== Make tools clobber ERRORS ====

A crypto tarball must be provided when there is no closed tree.

    then you're using a nightly from build 132 that broke the sfw build. It was fixed quickly, but in 133,
    which might matter if you're running OpenSolaris build 132 which might have SUNWonbld from 132 installed.

• Building on OpenSolaris build 131+ may fail because of this bug:

6918442 when /usr/bin/patch becomes gnu patch in opensolaris 131, it upsets a few things

    which is fixed in the build 133 source.

• If you get a failure like this:

==== Build errors (non-DEBUG) ====

dmake: defaulting to parallel mode.

    That generally means that you ran dmake, either directly or via $(MAKE), but didn't tell dmake to be parallel.
    nightly/bldenv force parallel mode by setting

DMAKE_MODE=parallel

    in the environment, so this means you also cleared that. Unfortunately that causes this message which nightly interprets
    as an error and thinks the build failed. This can be caused if you used 'env -[i]' in your Makefile.sfw and then ran $(MAKE).
    Since most things may not like dmake anyway, this likely means you really wanted to run $(GMAKE) or $(CCSMAKE) to force
    the use of GNU make or serial make. Note also that if you do that you need to set $(MAKE) in the environment to the same
    make or sub-Makefiles may use the wrong make.

• With 6442434 in ON now (103) these bugs have appeared and break the sfw build:

6753917 lftp defines-out "const", breaks AF_LOCAL & friends putback
6753918 bind in sfw can't compile if AF_LOCAL is defined. Bad variable name

• The build of stdcxx4 fails if your workspace variables (like SRC) go through a link (say you have SRC set to /builds/foo/usr/src but /builds is a link to /builds1). Other bits of the build can be affected too but weren't fatal. So don't do that.

• The build of freeipmi requires /usr/include/sys/bmc_intf.h, which first appeared in build 121.

• The build of guile/autogen may require the new SUNWltdl with 64-bit libraries to be installed.

• The build of quilt may require gawk to be installed.

• The 117 SUNWaconf package may break the sfw build.

• ocaml and lablgtk are now required. on 115 or so lablgtk may fail to build:

6841228 lablgtk does not build on latest gnome

• The recent addition of /usr/include/ncurses (103?) breaks the gdb build. Fixed in 106:

6781910 sfwnv nightly is broken due to ncurses

    However as of 115 the ncurses headers appear to have moved again, which breaks gdb/iftop.

6842390 ncurses headers moved again in 115 and it hurts

• On build 116 postgresql 8.2/8.3 may fail to build because of a header change in ON.

6845982 gcc4 cleanup breaks postgresql build

• In 106, the build of mpfr fails like this on amd64:

configure: error: please configure with ~--disable-thread-safe

    This is:

6792906 ld -z nopartial fix breaks TLS

• It seems that if you set SRC to /net/<somemachine>/... but then actually build on <somemachine> the build of libmcrypt fails.

• The minimal system requirements for building SFW are being bumped up to Nevada build 109 as Python 2.6 is needed.

For Further Information

General questions on the SFW consolidation should be directed to the discussion list at sfwnv-discuss@opensolaris.org. Please note that the mailing lists are configured to only allow posts from list subscribers or via the web forum interface. To subscribe, see the SFW Nevada project home.

Installing from Source

Once you have downloaded the SFW source, follow these steps to build it. Suppose you are using /export/sfwnv as your workspace.

• If your build machine is already configured for building ON, move to the next step. Otherwise, follow the compiler and onbld installation instructions in the ON README. These are steps 2, 3, and 4 in the onnv_36 README.

• Be sure that your installed copy of gcc is up to date:

    $ /usr/sfw/bin/gcc ~--version
    gcc (GCC) 3.4.3 (csl-sol210-3_4-20050802)

• Be sure that your installed copy of cc is up to date. If you've followed the above instructions, you should see:

    $ /opt/SUNWspro/bin/cc -V

 Correct output is architecture-dependent:

    cc: Sun C 5.8 Patch 121015-04 2007/01/10   (sparc/SS11)
    cc: Sun C 5.8 Patch 121016-05 2007/01/10   (x86/SS11)
    cc: Sun C 5.9 SunOS_sparc Patch 124867-08 2008/10/07 (sparc/SS12)
    cc: Sun C 5.9 SunOS_i386 Patch 124868-07 2008/10/07  (x86/SS12)

• Create an environment file to guide tools like nightly(1) and bldenv(1). It's best to start with one of the
  examples in usr/src/tools/env.

• change GATE to the name of the top-level directory (e.g.,"sfwnv")

• change CODEMGR_WS to the top-level path (e.g.,"/export/sfwnv").

• change STAFFER to your login.

• Do NOT set VERSION; this will break your build!

• The default options are recommended. Using other options may cause your build to fail or contain unnecessary noise.

• To build a complete set of archives, cd to /export/sfwnv, utter

    # env -i /opt/onbld/bin/nightly ./sfw-opensolaris.sh &

    and find something else to work on for a few hours. You can monitor the build's progress using ptree(1).
    nightly(1) will send mail to $MAILTO when it has finished. The results mail from nightly(1) will have
    an overview of the build results. A copy of the mail text and a more detailed log file will be available
    in the workspace (/export/sfwnv/log/log.DATETIME). Pieces of the detailed log are also available under
    usr/src. For example, usr/src/install-nd-i386.out will have the log from the x86 "make install" part of
    the build.

    By default nightly(1) will do a "clobber" build, which includes a "make clobber" and blowing away any
    files that earlier builds installed into $ROOT (/export/sfwnv/proto/root_PLATFORM). To bypass these steps
    do an incremental build with "env -i /opt/onbld/bin/nightly -i ./sfw-opensolaris.sh &". Be aware that
    incremental builds are not performed as often as in ON and do tend to break more frequently though.

• To build a specific component, first use bldenv(1) to set up various environment variables:

    # cd /export/sfwnv
    # env -i /opt/onbld/bin/bldenv ./sfw-opensolaris.sh
    [status information from bldenv]

    Next, you must create and partially populate the proto area:

    # cd $SRC
    # make setup

    Finally, cd into the directory containing the component you wish to build, and run make:

    # make -f Makefile.sfw install

    Note that all sub-makefiles are called Makefile.sfw to avoid possible collisions with the component's
    Makefile (if the tarball method is not chosen). You also might want to use 'dmake' instead.