Status for Andrew DeFaria

GD LOS178 Impact Summary

Export sources from LOS178

Export sources from LOS178 CVS tree using the CVS tag REL_LOS178_2p0p0_ppc_FCS. The export will come from the machine named Rock using CVSROOT=:pserver:anoncvs@rock:/cvs/los178-cvs:

tomcat:export CVSROOT=:pserver:anoncvs@rock:/cvs/los178-cvs
tomcat:cvs login
Logging in to :pserver:anoncvs@rock:2401/cvs/los178-cvs
CVS password:
tomcat:cvs export -r REL_LOS178_2p0p0_ppc_FCS los178

Extract prebuilt CDK

Extract prebuilt CDK (sunos-xcoff-ppc) binary also using the tag of REL_LOS178_2p0p0_ppc_FCS from Rock. Note that this prebuilt CDK comes from the bin-image section of the CVS repository and that we are only using the ppc.cdksol.tar.gz image:

tomcat:cvs export -r REL_LOS178_2p0p0_ppc_FCS bin-image/ppc.cdksol.tar.gz

Extract other tools

The package.sh script from the toolbox area is used to package up the images so we need to extract that too:

tomcat:cvs export -r REL_LOS178_2p0p0_ppc_FCS toolbox/package.sh

Test Build

Perform test build.

Steps performed are:

1. Create ppc_dev area to perform the build in:
   

   tomcat:mkdir ppc_dev
   

2. Copy in sources:
   

   tomcat:rsync -a los178 ppc_dev
   

3. Unpack CDK into build area
   

   tomcat:cd ppc_dev
   tomcat:gnutar -zxpf ../bin-image/ppc.cdksol.tar.gz
   

4. Perform build:
   

   tomcat:make DEVELOPMENT=yes install > install.log
   

5. Check install.log for errors

Perform binary comparison test

This binary comparison test is different from the normal binary comparison tests. Basically we are simply extracting all .o's from all .a's in the packaged versions of the product. A little utility script was written to find all .a libraries and copy them to an area (complibs) broken out by the path to the library, then extract all .o's from the .a's. This script is called unpack_libs. It is not intended that such a comparison be performed on a regular basis so this script is more of a one shot script.

Further, a build will create a lot of libraries but not all libraries created will be packaged and shipped. Since we are comparing against a previously built and packaged release we must package up and unpack the build we just performed. This is done using the toolbox/package.sh script as follows:

1. Package up the image just built:
   

   tomcat:toolbox/package.sh ppc_dev dev
   

2. Unpack images to new area:
   

   tomcat:mkdir new
   tomcat:cd new
   tomcat:for tarfile in ../media/*.tar.gz; do
   > gnutar -zxpf $tarfile
   > done
   

3. Gather all libraries and extract their .o's:
   

   tomcat:mkdir complibs
   tomcat:../unpack_libs
   

4. Unpack old images (from t3:/export/scl/los178/2p0p0/FCS/) to old area:
   

   tomcat:cd ..
   tomcat:mkdir old
   tomcat:cd old
   tomcat:# copy old tar images here
   tomcat:for tarfile in *.tar.gz; do
   > gnutar -zxpf $tarfile
   > done
   

5. Gather all libraries and extract their .o's:
   

   tomcat:mkdir complibs
   tomcat:../unpack_libs
   

6. Perform diff
   

   tomcat:cd ..
   tomcat:diff -r old/complibs new/complibs
   

7. The above will result in 25 .o files being different. Use objdump -D to disassemble these files and compare the disassembled output. No differences detected in disassembled output.

Import sources into new CVS repository

Sources will be imported into the CVS repository using the following command:

tomcat:cd los178
tomcat:export CVSROOT=:pserver:adefaria@tomcat:/cvs/hybrid-os-cvs
tomcat:cvs login
Logging in to :pserver:adefaria@tomcat:2401/cvs/hybrid-os-cvs
CVS password:
tomcat:# First add all directories
tomcat:find . ! -name CVS -type d -exec cvs add -m "HybridOS import from LOS178" {} \;
tomcat:# Now add all files
tomcat:find . -type f -exec cvs add -m "HybridOS import from LOS178" {} \;
tomcat:cvs commit

Additionally the binary CDK image was checked into binary-image:

tomcat:cd ../bin-image
tomcat:cvs add -m "HybridOS import from LOS178" ppc.cdksol.tar.gz
tomcat:cvs commit

Finally the toolbox/package.sh script as checked into toolbox:

tomcat:cd ../toolbox
tomcat:cvs add -m "HybridOS import from LOS178" package.sh
tomcat:cvs commit

Tag initial sources with the tag REL_HYBRIDOS_1p0_ppc_20050328

All sources, bin packages and toolbox scripts are then tagged:

tomcat:cvs tag REL_HYBRIDOS_1p0_ppc_20050328 los178 bin-image toolbox

Check out all sources and prebuilt CDK and perform build procedure again

Next we check out all sources, bin-image and toolbox scripts into new fresh areas and then perform the build procedure as described above.

Following successful build perform binary comparison test again

Perform the binary comparison described above again.

Package build to archive area

Use the package script to package up the images and place in the archive area at tomcat:/export/dev_archive/hybridos/1p0/20050328/solaris/media/ppc

Long standing issue regarding gnuaout vs. gnu

This has been bugging me for a while and I finally tracked it down. Often I'd build a toolchain then attempt to build LynxOS and it would fail when attempting to get the compiler. It seems that the toolchain build was packing up the compiler tar image with one name and the build scripts were using another name to try to find it. This resulted in errors. Now I had gotten around this via a symlink but I've been wanting to make the two build procedures agree on the names of things...

As Adam writes here the preferred name for the toolchain tar image is derived from config.guess:

Andrew DeFaria writes:

toolchain-i686-pc-linux-gnu-i386.tar.gz

This. But I think we get this from config.guess so try to see how this nice level of abstraction fails before you hard-code something.

The "toolchain-" portion is standard for the toolchain. The "i686-pc-linux-gnu" portion comes out of config.guess:

[int@dopey 20050207]$ /export/build1/LYNXOS_500/work_area/toolchain/3.2.2/toolchain/src/config.guess
    i686-pc-linux-gnu

However the int_tools uses the following code to determine the name of the toolchain tar image:

proc Unload_com { platform dir comp_release format host } {

  switch "$host" {
    "linux"  { set host_platform "i686-pc-linux-gnuaout" }
    "win32"  { set host_platform "i686-pc-cygwin" }
    "sunos"  { set host_platform "sparc-sun-solaris2.7" }
    "lynxos" { if { "$platform" == "x86" } {
                   set host_platform "i386-lynx-lynxos"
               }
               if { "$platform" == "ppc" } {
                     set host_platform "powerpc-lynx-lynxos"
               }
             }
  }
  if { "$platform" == "x86" } {
        set target_platform "i386"
  } else {
        set target_platform "$platform"
  }
  set COMPILER_TAR_GZ "toolchain-$host_platform-$target_platform.tar.gz"

The highlighted portion above is the line in error and the underlined portion should change to simply "gnu". The int_tools do not have the benefit of being able to call config.guess so this could likely break in the future again.

I will perform this change, along with other int_tool changes required for the new tag labeling under and ECR.