Check the make errors link for a list of known make failures by architecture. The make failures and other hard errors should be limited to 3rd party (e.g., X11) library mismatches. We have tried to reduce the warnings across all architectures, but in some cases, like signed/unsigned warnings, we stopped short of casting every blasted statement just to please a particular compiler implementation. In general, if the regression tests pass, don't worry. How's that for a plan?

You can build -g binaries for debugging in the default INSTALLROOT by:

     package make debug=1

     package make debug=1 HOSTTYPE=$(package)-debug

You can build individual components by first setting up the environment (PACKAGEROOT INSTALLROOT PATH VPATH CDPATH):

     bin/package use

     cd libast
     nmake [ -n ] [ -d1 ] [ target ... ]
      or
     mamake [ -n ] [ -d1 ] [ target ... ]

1. run

        package read
   

   in a directory that is cross mounted on all your local machines

2. create the file lib/package/admin/admin.db with one line for each machine containing:

        hosttype	hostname	packageroot
   

   where hosttype is the host architecture type as displayed by the package command (with no arguments), hostname is the host name, and packageroot is the package root directory name, prefixed by rsh:[host:] or ssh:[host:] if it is not a local mount, where host: specifies that only one copy to packageroot mounted on host is required.

3. run

        package admin make
   

   to build and

        package admin results [ on hostname ]
   

   to check results

4. the builds are done concurrently; each machine build is done by rsh(1)ing or ssh(1)ing to the machine, sourcing the .profile, sourcing lib/package/admin/admin.env if it exists, and then running package make

5. our master source admin.db currently controls 16 architectures

Some C compilers process different dialects or generate different binary formats based on command line options. The defaults are not always chosen wisely. Worse, vendors have a bad habit of changing the defaults between releases. This can lead to binary incompatibilities between hosts from the same vendor within a local network. So on some systems a cc script is generated to nail the compiler down. The script also takes the opportunity to cut out some of the noise from some compilers.

HOSTTYPE is used to name the target architecture for binaries generated by the C compiler. The package command determines HOSTTYPE by first checking the binaries that $CC (default cc(1)) generates. This may be different than the type reported by uname(1) or the local OS. This is the how package handles cross-compilation.

See cross compilation.

It is important for an $INSTALLROOT to present a consistent set of binaries and objects. For binary formats other than the default produced by cc(1) or for alternate cc(1) implementations an $INSTALLROOT/bin/cc command must be provided. This will ensure that all binaries produced under $INSTALLROOT are compatible:

1. invent a HOSTTYPE name for the binary format; ideally it should use the default HOSTTYPE listed by package as a prefix

        HOSTTYPE=foo.bar
   

2. create the architecture-specific INSTALLROOT and bin directories

        mkdir -p $PACKAGEROOT/arch/$HOSTTYPE/bin
   

3. create a cc script that coaxes the real cc to build $HOSTTYPE binaries; this script must contain a line matching ^HOSTTYPE=foo.bar$ and ideally a -dumpmachine option intercept:

        cat > $PACKAGEROOT/arch/$HOSTTYPE/bin/cc <<!
        : $HOSTTYPE cc wrapper : `date +%Y-%m-%d` :
        HOSTTYPE=$HOSTTYPE
        case $* in
        -dumpmachine) echo $HOSTTYPE; exit ;;
        esac
        full-path-to-the-real-cc  HOSTTYPE-specific-option(s) "$@"
        !
        chmod +x $PACKAGEROOT/arch/$HOSTTYPE/bin/cc
   

4. export HOSTTYPE=foo.bar or add a HOSTTYPE=foo.bar argument to the package(1) command to build or use foo.bar binaries

        package make HOSTTYPE=foo.bar
        package use HOSTTYPE=foo.bar
   

1. Make sure $PATH points to cc and ar for the local host architecture.
2. If you see core dumps from $SHELL then get into a different shell, export SHELL, and try package make again. We have seen PDKSH core dump in the package script.
3. Look at the output of package results to see if it hints at the problem.
4. To dig deeper, look at the unfiltered output of package verbose results, or edit the file named by package results path.
5. We have seen NFS problems (surprise) on our local network when NFS-2 and NFS-3 are mixed between different vendors, or when we fire off package make on a half dozen hosts on the same $PACKAGEROOT. To rule this out, run package make from a host that has $PACKAGEROOT in a native filesystem. One workaround that works on our sol7.i386 and unixware.i386 hosts is to keep $PACKAGEROOT as a master cross mount on all hosts, and to make $INSTALLROOT a symlink to a local filesystem on the hosts that have NFS trouble.

Generate a binary package archive by:

     cd $PACKAGEROOT/lib/package
     package write binary

     cd new-INSTALLROOT
     pax -m -rvf package.YYYY-MM-DD.NNNN.hosttype.tgz

     -s ',arch/[^/]*/,,'

The fastest build time is ~10 minutes on on a 600 Mhz linux.i386, on a local filesystem. The slowest times are ~1 hour on older sparcs, on an NFS filesystem. When everything is up-to-date it should take less than 3 minutes, even on NFS.

First, make sure that the libraries and headers are installed on your systems. Sometimes only a runtime environment is installed for a particular package (as opposed to a development environment.) If your system really has the libraries and headers, here is a quick workaround:

     export PACKAGE_bar=bar-root-dir

     export PACKAGE_bar_include=bar-include-dir
     export PACKAGE_bar_lib=bar-lib-dir

     :PACKAGE: foo

This is a sun backwards compatibility bug between /lib/libc.so and /lib/libnsl.a. Somewhere between 5.8 Generic_108528-11 and 5.8 Generic_108528-14 sun dropped the _libc_register_forkhandler symbol from libc.so; a bad move since any executable linked against the old libnsl.a needs this symbol at runtime because of hidden references, outside of user control, in /lib/libnsl.a[mt_misc.o]. The fix is to force a dynamic link for nsl by changing +lnsl to -lnsl in the ksh93 Makefile. This has been done since the 2002-09-15 release.

The ast libz.so handles 64 bit file sizes and offsets. The first attempt at this introduced binary incompatibilities; these have been fixed since the 2002-09-15 release.

This may be related to a /bin/sh here document or temp file bug. To bootstrap the source build you can download the latest standalone ksh binary, or try SHELL=path-to-bash, or resurrect an earlier sunos /bin/sh.