Status for Andrew DeFaria

• Investigated bug on Windows nmake of CDK
• Fixed build_los178 to properly build LOS178 2.1

Windows nmake bug for CDK build

There is still something wrong. Here's what I did:

• Obtained the following tarballs from the 20050628 archive:
  • 2000-00.los178_rsc_src.tar.gz
  • 2001-00.los178_src.tar.gz
  • 2013-00.los178_dev.tar.gz
  • 2015-00.los178_rsc_dev.tar.gz
• Unpacked those tarballs + ppc.cdkwin32.tar.gz into /tmp/los178
• Setup my environment properly (this includes VCVARS32.bat)
• cd'ed to src/cdk and performed make install > install.log 2>&1

I still have the error:

    Compiling coff.o
    coff.c(87) : fatal error C1083: Cannot open include file: 'family/ppc/arch_mem.h': No such file or directory
    NMAKE : fatal error U1077: 'cl.exe' : return code '0x2'
    Stop.
    make[1]: *** [WIN32_VS_UTIL] Error 2

It seems clear to me that the compiler cannot locate the include file family/ppc/arch_mem.h which does reside under $ENV_PREFIX/sys/include. Additionally it's clear that common/mkimage/Makefile was changed to append "-I$(ENV_PREFIX)/sys/include" to SPECIAL_CFLAGS to resolve this issue. However something on Windows (and Windows nmake) is causing this to remain a problem.

It seems that nmake eventually issues the following command to compile coff.c -> coff.o:

    cl.exe /nologo /ML /W3 /GX /D "_WIN32_VS" /D "_CONSOLE" /D "WIN32" /D "_MBCS" /FD /c -c coff.c -D__powerpc__ /Fo"coff.o"

Which, of course, doesn't seem to mention $ENV_PREFIX/sys/include at all. IOW the above results in:

    cl.exe /nologo /ML /W3 /GX /D "_WIN32_VS" /D "_CONSOLE" /D "WIN32" /D "_MBCS" /FD /c -c coff.c -D__powerpc__ /Fo"coff.o"
    coff.c
    coff.c(87) : fatal error C1083: Cannot open include file: 'family/ppc/arch_mem.h': No such file or directory

While the following results in a successful compilation (with warnings):

    cl.exe /nologo /ML /W3 /GX /D "_WIN32_VS" /D "_CONSOLE" /D "WIN32" /D "_MBCS" /FD /c -c coff.c -D__powerpc__ /Fo"coff.o" /I$ENV_PREFIX/sys/include

The Makefile and Windows nmake are not arranging for SPECIAL_CFLAGS to be passed along to the compiler.

Fix to build_los178

The build_los178 script was having a problem building LOS178. It would fail in different ways than when done from the command line. I suspected the problem would be in the setup_bash function as it attempts to reproduce what a ". SETUP.bash" does inside the Perl environment. Turns out I was right. Changed that subroutine to properly set HOST_OS_REVISION (previously it had an extra carriage return from `uname -r`) and to add /usr/ucb to the PATH.

Posted by at 10:21 AM | Permalink

• Completed the build of LOS178 2.1.0 TOB and released it to t3:/export/dev_archive/los178/2p1p0/20050628
• Updated cvs_report to not report duplicate entries. This can occur when somebody say checks in foo.c thus creating revision 1.2 for CR 40 and then checks in foo.c again, thus creating revision 1.3. Before cvs_report would report foo.c twice. Now it just reports the highest revision (e.g. 1.3).
• Updated cvs_report to take another parameter, -cvsr, for a cvs report area. cvs_report uses this area in order to determine what to report. Contained in this area is a .cvsr file which holds the baseline tag. However if you want to report on both the main trunk and a branch then you can't use the same area. In the past cvs_report was oriented to using the module name for the area. Now you can specify an alternate area.

Posted by at 2:32 PM | Permalink

• Build Windows version of the CDK
• Submitted CR 659: cdk tool mkimage fails to build under Windows

Building Windows CDK

In order to build the CDK under Windows one must use an ancient version of Cygwin - B20 (it is assumed that that is already installed). Additionally one must perform certain actions in a certain order:

1. Obtain the latest versions of the following tar images from the archive area:
   • 2000-00.los178_rsc_src.tar.gz
   • 2001-00.los178_src.tar.gz
   • 2013-00.los178_dev.tar.gz
   • 2015-00.los178_rsc_dev.tar.gz
   • (From cvs bin-image) ppc.cdkwin32.tar.gz
2. Create an area to do the build and extract the above into that area
3. Exit this bash shell
4. Start a cmd shell
5. Execute the VCVARS32.BAT file. This is normally found in C:\Program Files\Microsoft Visual Studio\VS98\Bin. Note that this implies that Visual Studio is also installed. Also, often people will copy this bat file to C:\ for easier execution. This bat file sets certain environment variables including PATH such that nmake can be found. Under Windows we lean on VS's nmake. Also, this must be done from a cmd shell before starting Cygwin so that the changes to the environment can be picked up. Why don't we just make a script or enhance SETUP.bash to take into account for this?
6. Start Cygwin using the appropriate cygnus.bat file. This was given to me by Moscow. Doesn't seem to do that much fancy stuff:

   @ECHO OFF
   SET TARGET_PATH=C:\LynuxWorks\2.0.0
   SET MAKE_MODE=UNIX
   SET TERM=cygwin
   SET HOME=/
   
   set PATH=%TARGET_PATH%\bin;%TARGET_PATH%\usr\bin:%PATH%
   
   echo "TARGET_PATH is %TARGET_PATH%
   
   if not exist %TARGET_PATH%\bin\sh.exe goto error_no_sh
   
   ver > %TARGET_PATH%\_tmp
   goto the_end
   
   :error_no_sh
   echo "Installation Error -- no %TARGET_PATH%\bin\sh.exe found"
   
   :the_end
   del %TARGET_PATH%\_tmp
   bash
   

7. cd to the directory that you created to perform the build
8. Source SETUP.bash
cd to src/cdk
9. make install > install.log 2>&1
10. Check install.log for errors

CR 659: cdk tool mkimage fails to build under Windows

Build of cdk tool mkimage files under Windows. This is a make install in src/cdk of LOS178. The specific error is:

Compiling coff.o
coff.c
coff.c(91) : fatal error C1083: Cannot open include file: 'family/ppc/arch_mem.h': No such file or directory
NMAKE : fatal error U1077: 'cl.exe' : return code '0x2'
Stop.
make[1]: *** [WIN32_VS_UTIL] Error 2 

Problem seems to be that the fix for src/cdk/common/mkimage/Makefile in CR #539 of adding -I$(ENV_PREFIX)/sys/include does not work under Windows with nmake.

Posted by at 10:35 AM | Permalink

• After two bugs in the GDB 6.0 build process on Solaris were fixed I was finally able to build GDB 6.0 on Solaris
• Built LOS178 for both dev and pdn
• Packaged up and released onto t3
• Tagged release with DEV_LOS178_2p1p0_ppc_20050622

Posted by at 7:19 PM | Permalink

• Managed to build los178 for dev and pdn. Pdn still has CONSOLE_DEVICE error on ibm44ep.
• Working with Adam re: GDB build on Rock

Rock (Solaris) build

Building on Rock is building on Solaris. We have to rebuild parts of the cdk by cd'ing into src/cdk and doing make install. This puts stuff into the cdk/-[xcoff|elf]- area. Now on Linux everything builds OK and I believe we also did the Window portion too. But Solaris was yet undone.

Turns out that not much builds successfully on Solaris but all that is required at this time is mkimage. With mkimage successfully built the process of building LOS178 on Solaria remains largely the same in that you checkout/export the sources and untar the ppc.cdksol.tar.gz. The difference is that you inject your newly built mkimage into the cdk area before building.

Packaging and Structuring

Vinnie attempted to describe the packaging structuring. I'm still not sure i have it all in my head yet but here goes:

Note that we are only currently building for release on Rock or Solaris. Still cdk's for other targets need to be built and included. Also, we use the bin-image/ppc.cdk.tar.gz prebuilt software for building things and we also package up cdk tarballs in the release area (e.g. 2011-01.cdksol.tar.gz).

For GDB we must source SETUP.bash pointing to some LOS178 area and then we go to the toolchain and make install-gdb. The end result of this build are two executables, one of which we are concerned with - gdbserver. However there are also various things deposited in the cdk for gdb, the client and for insight and Tcl/Tk stuff.

The gdbserver and it's client require packaging of Linux, Windows and Solaris cdk's that contain the necessary gdb parts. The current package.sh should automatically handle this because it packages up things based on directory names.

Posted by at 3:57 PM | Permalink

• Built LOS178 2.1.0 on Rock including CR638. Was able to build dev but not pdn.
• Having some problems with GDB build on Solaris

I was able to build LOS178 2.1.0 dev build on rock but had errors in building the pdn portion:

    rock:check -t -v ../los178.pdn/install.log
    ERRORS:
    conf.c(98) : error: `CONSOLE_DEVICE' undeclared here (not in a function)
    make[4]: *** [conf.o] Error 1
    make[3]: *** [re_all] Error 2
    make[4]: *** [common_all] Error 1
    make[3]: *** [re_all] Error 2
    make[4]: *** [a.out] Error 1
    make[3]: *** [re_all] Error 2
    make[2]: *** [real] Error 2
    make[1]: *** [install] Error 2
    File: ../los178.pdn/install.log Errors: 9 Warnings: 1140
    rock:pwd
    /export/home/adefaria/2.1.0/los178/los178.cvs

Also, I was only able to build mkimage for the cdk on Solaris. Vinnie says this is expected.

I have not managed to build gdb on Solaris, I'm working with Adam about that problem.

Posted by at 8:32 PM | Permalink

• Worked to build 3.0.0 from 3.4.3

Performed the following actions:

Change packaging by hand:

1. cd /build/toolchain/install-powerpc178/cdk/linux-elf-ppc
2. mkdir bin
3. cd bin
4. Created symlinks for the following: ar, as, byacc, c++, cc, cmp, diff, diff3, expect, flex, gcc, ld, make, nm, ranlib, size, strip to link to ../usr/bin (exception: cc -> ../usr/bin/gcc). Note: byacc, c++, cmp, diff, diff3 and expect do not exist in ../usr/bin! Removed symlinks
5. cd ../..
6. mkdir lib
7. Copied cdk/linux-elf-ppc/usr/lib/gcc/powerpc-lynx-lynxos178/3.4.3/libgcc.a -> lib Note: Unable to find any libstdc++.a's!
8. Created linux-elf-ppc.tar.gz with tar -zcvf ../linux-elf-ppc.tar.gz .

Removing libgcc from LOS178:

1. cd /build/los178/src/lib/libgcc
2. rm Makefile
3. cvs delete Makefile
4. cd ..
5. Editted Makefile to remove libgcc from SUBCOMPONENTS
6. cd /build/los178/src/cdk/common/bison-1.19
7. rm Makefile
8. cvs delete Makefile (Note: there are many other files here. Should they be likewise removed?)
9. cd ../links
10. rm Makefile
11. cvs delete Makefile
12. cd /build/los178/src/cdk
13. Editted Makefile to remove references to bison-1.19 and links
14. Editted Makefile to add -0.9.6 to "openssl".

The following is the result of building src/cdk:

• coffcorrupt - for test PASSED
• cofflook - for inspecting coff object PASSED
• config - needed PASSED
• crc - append script uses this PASSED
• elflook - for inspecting elf object FAILED
• install - use for installation PASSED
• m4-1.4 - needed for config.tbl Didn't find anything about this!
• man2html - html man page utility Didn't find anything about this!
• mkbootprep - use by vmpc PASSED
• mkimage - maybe need to be update to support elf kernel? PASSED
• mktimestamp - needed for kernel timestamp PASSED
• prepend-crc - mkboot178 uses this PASSED
• gzip-1.2.4 - only for solaris host PASSED
• tar-1.11.2 - only for solaris host FAILED
• vctchk - use for checking vct FAILED
• openssl (Failed to build saying it couldn't find /build/los178/cdk/linux-elf-ppc/bin/make)

I will try to pick this up from home but I have been having some connectivity issues lately...

Picking up...

Building LOS178 after sections I & II above completed:

1. Logged in as int
2. Exported toolchain source -> /build/toolchain.src (via tag DEV_LOS178_3p0p0_ppc_20050607)
3. Instructions say to package source yet Makefile's package target does not include fixup.sh so performed this by hand.
4. Stored previously successfully built toolchain -> t3:/export/dev_archive/los178/3p0p0/toolchain/20050607
5. Checked that europa:/build/los178 had TOT. Only differences were the changes to the Makefile(s) describe above and the cvs deletes that I did.
6. rm sys/miscgcc/*.o
7. tar -zxvf /build/bin-image/ppc.cdksol.tar.gz sys/miscgcc
8. tar -zxpf/build/1033-00.cdklinux.tar.gz
9. Sourced SETUP.bash
10. make DEVELOPMENT=yes install > install.log 2>&1
11. make failed due to lack of crc (and a syntax error I introduced in the src/lib/Makefile - missed a "\"!). The crc was missing because I skipped a step, the make install in src/cdk. Turns out I skipped this step because I thought we had performed this yesterday - and we did - but we had some problems there and Vinnie helped me to get that to work. Unfortunately we were using make all during that time and failed to to the make install portion).
12. make failed with the following:

          europa:check -t -v install.log
          ERRORS:
          make[3]: *** No rule to make target `_udivdi3.o', needed by `archive_step'.  Stop.
          make[3]: *** No rule to make target `install'.  Stop.
          make[3]: *** No rule to make target `install'.  Stop.
          make[3]: *** No rule to make target `install'.  Stop.
          make[3]: *** No rule to make target `install'.  Stop.
          make[3]: *** No rule to make target `install'.  Stop.
          /build/los178/cdk/linux-xcoff-ppc/bin/ld: cannot open -lmiscgcc: No such file or directory
          make[4]: *** [common_all] Error 1
          make[3]: *** [re_all] Error 2
          /build/los178/cdk/linux-xcoff-ppc/bin/ld: cannot open -lmiscgcc: No such file or directory
          make[4]: *** [a.out] Error 1
          make[3]: *** [re_all] Error 2
          make[2]: *** [real] Error 2
          make[1]: *** [install] Error 2
          make[3]: *** [gunzip] Error 1
          make[3]: *** [nohup] Error 1
          make[3]: *** [install_common] Error 1
          make[3]: *** [install] Error 1
          make[2]: *** [real] Error 2
          make[1]: *** [install] Error 2
          File: install.log Errors: 20 Warnings: 2545
    

    The issues here boil down to the _udivd3.o problem mostly (the No rule to make target `install' are the csp.x86, ibm440ep stuff and there are few permissions problems with chmod since this build was done as int this time). The _udivd3.o problem results from a new .o file introduced by Gilbert and CR #542 and a corresponding change to the Makefile. The miscgcc .o files are gotten from ppc.cdksol.tar.gz but there is no _udivd3.o in ppc.cdksol.tar.gz.

    After discussing this with Vinnie we determined that Gilbert had checked in these .o files when what really needs to be done is for us to include this new .o file into the ppc.cdk[sol|linux].tar.gz images in bin-image.

13. After building the following errors remain:
    1. 5 "No rule to make target `install`" remains for devices.ibm440ep, drivers.ibm440ep, csp.440, csp.x86 and bsp.ibm440ep. These are known problems.
    2. Various permissions problems dealing with the fact that I had initially built things as adefaria and switched to building as int.

Posted by at 4:17 PM | Permalink

• Rebuilt/re-released 2.1.0 with additional CR #632
• Built GDB 6.0 on Windows!

Posted by at 12:18 PM | Permalink

• Added CR 636: LOS178 3.0.0 build fails with new 3.4.3 gcc
• Reproduced make clobber problem
• Added 637: 3.4.3 toolchain does not package properly

Make clobber problem

When a make clobber is performed in sys the make is propagated downward through the sub makes. However the sys level Makefile starts it's clobber target with: rm $(ENV_PREFIX)/sys/lib/* to remove all of the libraries in sys/lib.

When the make clobber gets propagated down to drivers/arinc653 the following happens:

    make -f Makefile.real DRV_IS_DLDD=no clobber
    make[1]: Entering directory `/build/los178/sys/drivers/arinc653'
    /bin/rm -f arinc653drvr.lint
    /build/los178/cdk/linux-elf-ppc/usr/bin/ar d /build/los178/sys/lib/libdrivers.a arinc653drvr.o
    make[1]: Leaving directory `/build/los178/sys/drivers/arinc653'
    make -f Makefile.real DRV_IS_DLDD=yes clobber
    make[1]: Entering directory `/build/los178/sys/drivers/arinc653'
    /bin/rm -f arinc653.*.o arinc653.*.bin arinc653.pre arinc653.import
    /bin/rm -f arinc653.dldd arinc653.info
    make[1]: Leaving directory `/build/los178/sys/drivers/arinc653'

At this point a small libdrivers.a is left in sys/lib:

    europa:ll ../../lib/libdrivers.a
    -rw-rw-r--    1 adefaria staff         170 Jun 13 13:02 ../../lib/libdrivers.a

Similar things happen in:

• sys/drivers/mem
• sys/driverspmac_g5/is_sungem
• sys/drivers.vmpc/rs232
• sys/drivers.vmpc/bdlan
• sys/drivers.vmpc/if_dec21040

When we are done with a clobber we are left with:

    europa:ll ../../lib/
    total 20
    drwxrwxr-x    2 adefaria staff        4096 Jun 13 13:16 ./
    drwxrwxr-x   26 adefaria staff        4096 Jun 13 13:16 ../
    -rw-rw-r--    1 adefaria staff         170 Jun 13 13:16 libdrivers.a
    -rw-rw-r--    1 adefaria staff           8 Jun 13 13:16 libdrivers_pmac_g5.a
    -rw-rw-r--    1 adefaria staff           8 Jun 13 13:16 libdrivers_vmpc.a

This eventually screws up the build. Doing a make clobber followed by rm lib/* then a make install works OK...

Posted by at 8:57 PM | Permalink

I experienced the following issues when attempting to build LOS178 with the 3.4.3 toolchain:

Need to have xcoff cdk

In order to perform the build the xcoff version of the cdk needs to be untarred. This was obtained from 2.0.0 (98r2) tarball:

    $ tar -zxpf ../1033-00.cdklinux.tar.gz

Need to get files from ppc.cdksol.tar.gz from sys/miscgcc

In order to perform the build one needs to extract files from bin-image/ppc.cdksol.tar.gz, specifically the sys/miscgcc area:

    $ tar -zxpf ../bin-image/ppc.cdksol.tar.gz sys/miscgcc

Need to extract 3.4.3 toolchain

After successfully building 3.4.3 gcc, package it up and then use it to extract here:

$ tar -zxpf ../toolchain/toolchain-i686-pc-linux-gnu-powerpc178.tar.gz

Toolchain's cdk/linux-elf-ppc lacks a bin directory

Normally under cdk/linux-xcoff-ppc there is both a usr and a bin directory. Some entities are just a symlink back to their counterparts in ../usr/bin (e.g. ld -> ../usr/bin/ld). This bin directory structure is not present after untarring toolchain-i686-pc-linux-gnu-powerpc178.tar.gz. For building purposes the following was done:

1. Create a bin directory in cdk/linux-xcoff.ppc
2. Create symlinks to ../usr/bin:

         $ for link in ar as byacc c++ cmp diff diff3 expect flex gcc ld \
         > make nm ranlib size strip; do
         > ln -s ../usr/bin/$link $link
         > done
   

   Note: Some of these are probably not necessary
3. Copy the following files from linux-xcoff-ppc/bin -> linux-elf-ppc/bin:

         $ for file in bison bison.hairy bison.simple coffcorrupt cofflook \
         > config crc elflook gnutar gunzip gzcat gzexe gzip install mkbootprep \
         > mkimage mktimestamp prepend-crc vctchk yacc zcmp zdiff zforce zgrep \
         > zmore znew; do
         > cp ../../linux-xcoff-ppc/bin/$file $file
         > done
   

   Note: Some of these are probably not necessary

libgcc.a not present

The build failed because it was unable to find libgcc.a. The solution was to copy libgcc.a into the right place:

    $ mkdir lib
    $ cp cdk/linux-elf-ppc/usr/lib/gcc/powerpc-lynx-lynxos178/3.4.3/libgcc.a lib

Posted by at 3:53 PM | Permalink

• As Moscow had checked in changes I was instructed to reattempt to build 3.4.3 toolchain again. Toolchain builds on both RH 8.0 and 9.0 but LOS178 fails to build
• Made changes to LOS178 top level Makefile to support global clean and clobber targets. Need CR to check this in...

3.4.3 Toolchain builds

Andrew,

On the other part I just wrote the high level instruction you know what to do.

--Vinnie

1. check out compiler TOT from t3:/cvs/gcc-cvs

# cvs co -P toolchain

2. Apply tag DEV_LOS178_3p0p0_ppc_20050609

To the toolchain?!?

3. check out los178 & check out bin-image (TOT)

# cvs co -P bin-image
# cvs co -P los178

OK.

4. Apply tag DEV....... you know what this is

I assume you mean to los178... (bin-image?)

5. extract linux cdk (98r2) into the los178 build tree

t3:/export/dev_archive/los178/2p0p0/20050228/solaris/media/ppc/1033-00.cdklinux.tar.gz

OK

6. extract sys/miscgcc from bin-image/ppc.cdksol.tar.gz into los178 build tree

# gnutar zxpf bin-image/ppc.cdksol.tar.gz sys/miscgcc

This is needed since kernel is still xcoff. Once kernel is elf you will need elf miscgcc object files.

OK.

7. In the los178 build tree source SETUP.bash

OK.

8. Change to the toolchain directory & do whatever setup is needed and build the compiler

OK. Damn it worked! (RH 9.0 - still waiting for RH 8.0...)

9. package the toolchain & extract into the los178 build tree

OK

10. build the los178

Experienced problems. First problem is that cdk/linux-elf-ppc lacked a bin directory, therefore $ENV_PREFIX/cdk/linux-elf-ppc/bin/make did not exist. Looking at linux-xcoff-ppc/bin I see that some files are simply symlinks to ../usr/bin/ and others are actual files. Using the file(1) command I see that the files under linux-xcoff-ppc/bin that are not symlinks are ELF files! Odd.

So recreating (symlinking symlinks and copying files) $ENV_PREFIX/cdk/linux-xcoff-ppc/bin -> $ENV_PREFIX/cdk/linux-elf-ppc/bin and attempting the build yielded errors. Discussing this with Vinnie we performed the following actions:

• Copied cdk/linux-elf-ppc/usr/lib/gcc/powerpc-lynx-lynxos178/3.4.3/libgcc.a -> $ENV_PREFIX/lib
• Created the /usr/los178/2.0.0/ppc_dev/cdk/linux-xcoff-ppc/bin directory and placed a copy of bison.simple from cdk/linux-xcoff-ppc/bin into that directory
• Reperformed the build of LOS178

Now, on Europa - a RH 8.0 machine - I have many errors all stating:

    /build/los178/cdk/linux-xcoff-ppc/bin/ar: /build/los178/sys/lib/libdrivers.a: File format is ambiguous
    /build/los178/cdk/linux-xcoff-ppc/bin/ar: Matching formats: elf32-powerpc elf32-little elf32-big
    make[5]: *** [/build/los178/sys/lib/libdrivers.a(rddrvr.o)] Error 1

The log file is on europa:/build/los178/install.log

Global clean and clobber targets

In order to support global clean and clobber targets on LOS178's top level Makefile the following changes need to be done:

• Add clean and clobber to .PHONY
• Change help target to describe new targets
• Add clean and clobber targets that essentially loop through $(DIRS) and perform make [clean|clobber]

Via cvs diff:

Index: Makefile
===================================================================
RCS file: /cvs/los178-cvs/los178/Makefile,v
retrieving revision 1.7
diff -r1.7 Makefile
22c22
< .PHONY: help all install setup asmstat asmstatclean
---
> .PHONY: help all install setup asmstat asmstatclean clean clobber
24a25
>       @echo "This Makefile is use to build the entire LOS178, for example:"
26,27d26
<       @echo "This Makefile is use to build the entire LOS178"
<       @echo " for example:"
31c30,33
<
---
>       @echo "Additionally the following targets are supported"
>       @echo ""
>       @echo "     make clean"
>       @echo "     make clobber"
55a58,66
>
> # Global clean and clobber targets
> clean:
>       @for dir in $(DIRS); do \
>               (cd $$dir && make clean); done
>
> clobber:
>       @for dir in $(DIRS); do \
>               (cd $$dir && make clobber); done

Posted by at 3:05 PM | Permalink

• Rebuilding LOS178 2.1.0
• Attempted to build 3.4.3 on RH 8.0. Didn't work. Reattempting on RH 9.0 machine, shrike
• Setup coolcat Windows box to attempt to build GDB 6.0
• Changed Logger.pm to set autoflush
• Changed build_los178 to look for sendmail
• Worked on improving rename.sh to handle multiple versions. More works need to be done.

LOS178 2.1.0

There was some sort of problem with the recent build of 2.1.0. In looking into it I found the following:

I found a tagging problem. I used the tag DEV_LOS178_3p0p0_ppc_20050603. Note the 3p0p0. It should have been 2p1p0. I searched dev_archive on t3 and find no 20050603 directory for 3p0p0 but find it instead under 2p1p0. I believe that I should simply rename that tag to DEV_LOS178_2p1p0_20050603.

The CRs involved in 1 gig support seem to be: 539 and 606. Additionally 620 appears to be picked. Here's the break down:

    rock:files4cr 539 # Add 1Gb support for LynxOS-178
    ENVIRONMENT: 1.9.2.2 - Already up to date
    src/bin/lynxos.boot/Makefile: 1.1.1.1.2.1 - Already up to date
    src/cdk/common/mkimage/coff.c: 1.1.2.1 - Already up to date
    sys/bsp.vmpc/bsp_env.c: 1.2.2.1 - Already up to date
    sys/bsp.vmpc/lowInit.c: 1.3.2.1 - Already up to date
    sys/bsp.vmpc/procinit.c: 1.3.2.1 - Already up to date
    sys/csp.970/csp_init.c: 1.2.2.1 - Out of date
    sys/csp.970/csp_mem_map.c: 1.4.2.1 - Out of date
    sys/csp.ppc/csp_init.c: 1.2.2.1 - Already up to date
    sys/csp.ppc/csp_mem_map.c: 1.3.2.1 - Already up to date
    sys/include/bsps/pmac_g5/board.h: 1.5.2.1 - Out of date
    sys/include/bsps/vmpc/board.h: 1.2.2.1 - Already up to date
    sys/include/bsps/vmpc/pwb.h: 1.1.2.1 - Already up to date
    sys/include/family/ppc/arch_mem.h: 1.1.1.1.2.1 - Already up to date

    rock:files4cr 606 # Fix the 1GB problem on the Apple Power Mac G5 LynxOS-178 BSP
    sys/bsp.pmac_g5/bsp_env.c: 1.2.2.1 - Already up to date
    sys/bsp.pmac_g5/bsp_init.c: 1.3.2.2 - Already up to date
    sys/bsp.pmac_g5/ofw.c: 1.5.2.1 - Already up to date
    sys/bsp.pmac_g5/ofw.h: 1.3.2.1 - Already up to date
    sys/bsp.pmac_g5/procinit.c: 1.5.2.1 - Already up to date
    sys/csp.970/csp_init.c: 1.2.2.2 - Already up to date
    sys/csp.970/csp_mem_map.c: 1.4.2.2 - Out of date
    sys/include/bsps/pmac_g5/board.h: 1.5.2.2 - Already up to date
    sys/kernel/getrusage.c: 1.1.1.1.2.1 - Already up to date

    rock:files4cr 620 # Import G5 bug fixes/improvement from TOT into 2.1.0 branch
    sys/bsp.pmac_g5/bsp_intr.c: 1.2.2.1 - Already up to date
    sys/csp.970/csp_mem_map.c: 1.4.2.3 - Already up to date
    sys/drivers/arinc653/Makefile.real: 1.1.2.1 - Already up to date

If you look carefully you'll notice that the "Out of date" items for 539 are covered with newer versions in 606 and 620. So it appears as if I was up to date with when I built.

I am building again and will be rereleasing images using the correct numbering this time.

Building 3.4.3 gcc on shrike RH 9.0

I attempted to build 3.4.3 gcc on shrike, a RH 9.0 system but it failed with the following:

    make[2]: Entering directory `/home/adefaria/toolchain/build-powerpc/bison'
    cd /home/adefaria/toolchain.orig/src/bison && autoheader
    WARNING: Using auxiliary files such as `acconfig.h', `config.h.bot'
    WARNING: and `config.h.top', to define templates for `config.h.in'
    WARNING: is deprecated and discouraged.

    WARNING: Using the third argument of `AC_DEFINE' and
    WARNING: `AC_DEFINE_UNQUOTED' allows to define a template without
    WARNING: `acconfig.h':

    WARNING:   AC_DEFINE([NEED_MAIN], 1,
    WARNING:             [Define if a function `main' is needed.])

    WARNING: More sophisticated templates can also be produced, see the
    WARNING: documentation.
    touch /home/adefaria/toolchain.orig/src/bison/config.hin
    cd . && /bin/sh ./config.status config.h
    Usage: ./config.status [--recheck] [--version] [--help]
    make[2]: *** [stamp-h1] Error 1
    make[2]: Leaving directory `/home/adefaria/toolchain/build-powerpc/bison'
    make[1]: *** [all-bison] Error 2
    make[1]: Leaving directory `/home/adefaria/toolchain/build-powerpc'
    make: *** [stamp-all-powerpc] Error 2

Here's what I did:

• Checked out toolchain from my previous tag (DEV_LOS178_3p0p0_ppc_20050607)
• Obtained and applied the patches as before
• Obtained the LOS178 build environment as before
• Performed make install

This was done on shrike in my home directory.

Posted by at 5:11 PM | Permalink

• Changed build_los178 to log results using Logger and to report results by emailing them
• Started on 3.4.3 toolchain build

Posted by at 2:29 PM | Permalink

• Built LOS178 2.1.0

Posted by at 2:33 PM | Permalink

• Built TOT for LOS178
• Tagged and release resultant build
• Worked some more on build_los178 script to do automatic building

Automatic building

In general this is going to be hard because each systems has it's own build mechanism and quirks. The intend was initially to create a script that normalized those quirks but it was later decided to create a build_los178 script that has particular knowledge of LOS178.

So far the set up and initial build steps are done. It's not optimal, more like a mirroring of the steps that a builder would do - but it's a start. One problem is that through Perl one cannot expect to `. SETUP.bash` and expect environment variables to remain in force. This is because Perl execs a subshell to perform the command and after that subshell dies so does its environment. For now build_los178 has a subroutine coded that mimicks what SETUP.bash does. This is not good because if SETUP.bash changes then that would break this until it was likewised changed. I need to find a better way to do this...

Posted by at 5:24 PM | Permalink