OpenSolaris

SFW Buildable Source for OpenSolaris

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

1. 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:

1. compiler: Sun Studio 12 with patches as delivered for ON
2. compiler: gcc 3.4.3 with patches as delivered with Solaris Express build 22 or later, or SFW build 22 or later.
3. 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 OpenSolaris distribution compatible with the Solaris Express release two builds older than the SFW sources. Consult your vendor's documentation for more information about compatibility with Solaris Express. For example, to build SFW sources for build 58, your distribution must be compatible with Solaris Express build 56 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.

 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

1. 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.
2. 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.
3. The package builds may fail on large ZFS file systems (6459131 and 6558284).
4. If you are building x86 binaries, you must use a 64-bit build machine running the 64 bit kernel (6401063).
5. 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.
6. 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.
7. 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.
8. 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.

1. 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.

1. 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

1. 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.
2. the build of freeipmi requires /usr/include/sys/bmc_intf.h, which first appeared in build 121.
3. The build of guile/autogen may require the new SUNWltdl with 64-bit libraries to be installed.
4. The build of quilt may require gawk to be installed.
5. The 117 SUNWaconf package may break the sfw build.
6. ocaml and lablgtk are now required. on 115 or so lablgtk may fail to build:

6841228 lablgtk does not build on latest gnome

1. 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

1. 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

1. 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

1. It seems that if you set SRC to /net/<somemachine>/... but then actually build on <somemachine> the build of libmcrypt fails.
2. 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.

1. If your build machine is already configured for building ON, skip ahead to step 2. Otherwise, follow the compiler and onbld installation instructions in the ON README. These are steps 2, 3, and 4 in the onnv_36 README.
2. 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)

1. 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)

1. Create an environment file to guide tools like nightly(1) and bldenv(1).

1. change GATE to the name of the top-level directory (e.g.,"sfwnv")
2. change CODEMGR_WS to the top-level path (e.g.,"/export/sfwnv").
3. change STAFFER to your login.
4. Do NOT set VERSION; this will break your build!
5. The default options are recommended. Using other options may cause your build to fail or contain unnecessary noise.
6. To build a complete set of archives, cd to /export/sfwnv, utter

    # /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.DATE). 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 "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.

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

    # cd /export/sfwnv
    # 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).