portgd, 3.0.0 TOT build again
- Portgd still not working well
- Build 3.0.0 TOT again
- Added package of pdn to 2.1.0. Somehow I missed it
- Repackaged cdklinux
Continue reading "Linux ABI build failure/GDB Build failure" »
The CDK was not properly packaged before. Here's what needs to be done. Because we built GDB we need to get the GDB client software into the LOS178 CDK area. This is done by performing a make package-gdb in toolchain to obtain a tarball for GDB. This process also creates a toolchain source tarball, which takes quite some time and space and it largely not needed.
Then you need to unpack this GDB tarball into the LOS178 CDK area. Then you can tar up the CDK (for Linux and Windows) or use package.sh (Solaris).
In order to build LOS178 2.1.0 on Windows the following steps were performed:
In order to build LOS178 2.1.0 on Linux the following steps were performed:
Continue reading "3.4.3 toolchain build/LOS178 Makefile global clean/clobber" »
I experienced the following issues when attempting to build LOS178 with the 3.4.3 toolchain:
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
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
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
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:
$ 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
$ 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
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
Continue reading "3.4.3 toolchain build/LOS178 Makefile global clean/clobber" »
Both files4ecr and files4cr will suffer this same problem. Let's say we had an E/CR with 10 files modified. If at some later time one of these 10 files is changed, or another file modified with this same E/CR number it will show up in the CVS Report as only that one file modified since the CVS Report goes from some base tag to some other tag (e.g. head). The difference between those tags is only that one file - rightfully so.
However both files4ecr and files4cr work off of the E/CR number identifying all files associated with that E/CR number, irrespective of any other tags that they might have. So the files4cr in the above scenario would pick up all 11 files!
Now according to CVS a commit command should not commit files that have not been modified. The question is what does CVS use to determine that a file has been modified? Contents modified or just say date/timestamp modified? It appears that it's content modified
Still this makes files4[e]cr not very efficient. For example, CR #542 consists of ~3200 files that were modified. Since the last dev build 17 more files were modified. But files4cr picks up ~3200 files! If we are to transfer these over to GD then commit that seems like a large waste of effort
Wrote the following to Sasha today:
I'm still trying to build BC on RH 8.0. Since I was successful at building BC 5.3 on RH 6.1 I figured I oughta try building BC 5.3 on RH 8.0. I am also building starting as root.
I've tried twice now and it continues to fail in step 4.1 building the kernel. The following appears in build_kernel.log:
+ echo BUILDING A KERNEL FOR pmac_g5...
+ cp /build/bluecat/build/20050429/cdt/src/bluecat/SOURCES/bluecat-pmac_g5.config arch/ppc/defconfig
+ rm -f .config
+ make mrproper
+ make oldconfig
/bin/sh: line 1: bc_native_gcc: command not found
make[1]: *** [scripts/basic/fixdep] Error 127
make: *** [scripts_basic] Error 2
error: Bad exit status from /build/bluecat/build/20050429/var/tmp/rpm-tmp.94728 (%build)
Bad exit status from /build/bluecat/build/20050429/var/tmp/rpm-tmp.94728 (%build)
Apparently var/tmp/rpm-tmp.94728 is a build script built on the fly then executed. bc_native_gcc does exist in /usr/src/bluecat/eng/bluecat/bc_misc but this script can't find it.
Ideas?
The more I look into CVS the less I understand. Perhaps you can help me...
For the file los178/sys/kernel/getmem.c I see the following:
saturn:cvs log getmem.c
RCS file: /cvs/los178-cvs/los178/sys/kernel/getmem.c,v
Working file: getmem.c
head: 1.2
branch:
locks: strict
access list:
symbolic names:
DEV_LOS178_2p1p0_ppc_20050503: 1.1.1.1.2.1
REL_LOS178_2p0p0-branch: 1.1.1.1.0.4
...
REL_LOS178RSC_2p0p0_ppc_FCS: 1.1.1.1
...
saturn:cvs st getmem.c
===================================================================
File: getmem.c Status: Up-to-date
Working revision: 1.1.1.1
Repository revision: 1.1.1.1 /cvs/los178-cvs/los178/sys/kernel/getmem.c,v
Sticky Tag: REL_LOS178_2p0p0_ppc_FCS (revision: 1.1.1.1)
Sticky Date: (none)
Sticky Options: -ko
In particular here notice that head says 1.2 but the current working revision is 1.1.1.1. The CVS Report does a:
saturn:cvs diff --brief -r HEAD getmem.c saturn:
Does this mean that there is no difference between 1.1.1.1 and 1.2?!? However if I do:
saturn:cvs diff --brief -r 1.2 getmem.c Index: getmem.c =================================================================== RCS file: /cvs/los178-cvs/los178/sys/kernel/getmem.c,v retrieving revision 1.2 retrieving revision 1.1.1.1 diff --brief -r1.2 -r1.1.1.1 Files /tmp/cvsvGa4M1 and /tmp/cvswGa4M1 differ saturn:
Why is this so? Doesn't -r HEAD mean 1.2 in this instance?
I spent some time improving the web based CVS Reports. As you know I recently added reporting for Bluecat Eng and Bluecat Pkgs. But I've also improved the detailed report (e.g. See the 05/05/2005 report for Bluecat Eng) in the following ways:
I encourage you to visit these reports. They really can be quite useful. Maybe we can finally turn off the daily email.... ?
Vinnie pointed out that the packaging script for LOS178 fails to include libstdc++.a. I've looked into this and found that while libstdc++.a is part of 2.1.0, 3.0.0 and GD the packaging script for all 3 failed to include libstdc++.a in the tar images. Further, 3.0.0 includes CR 542, the new TCPIP stack, yet the packaging script does not package up the new TCPIP stack. GD also included the new TCPIP stack ported under CR 15 and I had modified the packaging script on GD to do that.
Here's what I think should happen:
Performed the following functions:
Question: Should this tag be added to TagsLog or are DEV tags not to be documented in TagsLog.
In step 3 of the build process a build of glibc continues to fail. In debugging this I got down to:
/build/bluecat/build/20050319/cdt/bin/rpmbuild -ba --rmsource --clean /usr/src/bluecat/packages/glibc/SPECS/glibc_cdt.spec --bluecat_cdt=i386-bluecat-linux
This rpmbuild command is building both source and binary rpms and effectively goes through a building process. After a long time it eventually fails with:
RPM build errors:
File not found: /build/bluecat/build/20050319/var/tmp/glibc-2.3.2-root/cdt/\
share/info/libc.info
File not found: /build/bluecat/build/20050319/var/tmp/glibc-2.3.2-root/cdt/\
share/info/libc.info-1
File not found: /build/bluecat/build/20050319/var/tmp/glibc-2.3.2-root/cdt/\
share/info/libc.info-10
...
Looking in /build/bluecat/build/20050319/var/tmp/glibc-2.3.2-root/cdt/share/info I do see those files but they are gzipped (end in .gz). The rpmbuild command therefore returns a non zero status and due to bad error handling it looks as if the failure is somewhere else, but no it's here.
Also it seems like this directory, or at least the "var/tmp" portion of the path seems to indicate that this is a temporary directory, perhaps created by the rpmbuild itself so I'm not sure if simply unzipping the files will make this rpmbuild succeed or not.
This status entry is to hold a log of the issues and resolutions for getting the Bluecat build process from the ancient RH 6.1 to the a little less ancient RH 8.0.
Continue reading "Tagged HybridOS/Bluecat RH 8.0 building" »
Continue reading "NetSNMP/Native x86 toolchain problems/ECR Linkify" »
Continue reading "Native x86 toolchain/Bluecat Installation/ECRD timeouts" »
Spent most of the day attempting to build the TOB Toolchain by first tagging it with DEV_LYNXOS_3P2P2_ALL_20050207. The tagging operation has some problems and I suspect not everything that needed to get tagged got tagged.
Have been hunting down and tagging things hopefully appropriately in order to get things to build but I'm still having some problems.
Changed cvs_report.pl to:
Changed http://saturn.lynx.com/cvsr to generate HTML from the above datafiles.
Vinnie pointed out that there was some sort of problem with CVS on Monday, the date that I had gotten the sources out of CVS. Ends up some files were missing so I had to redo the PPC cross build.
I've updated cvs_report.pl to be more parameterized and flexible. One goal was to make it smart enough to produce a report showing the ECRs between two labels. This is helpful when one wants to get the ECRs that were picked up in this build.
Thu helped me recover from the makeboot -r 0,48 preboot. This LynxOS 5.0.0 has not networking so I booted back up to the b partition (LynxOS 4.0.0) and mounted the c partition. Next I got X/Motif from t3:/export/dev_archive/lynxos/xmotif/032504 (note that this tarball was named 20010.xfree86.tar.gz) and unpacked it onto the c partition. It is important that XFree is unpacked into the partition and root diretory where LynxOS is.
I had already copied toolchain-src.tar.gz over to the k partition and unpacked under toolchain/3.2.2/010405
Next boot up back to the 5 partition and mount the k partition. SETUP.bash for "/" then go to toolchain/3.2.2/010405 and make install...
Attempting to learn and document how to load the LynxOS manually. Normally the int_tools handles this process but occasionally we need to do this by hand.
Messed up by not following all the required steps. Had to get a CD from Hardev in order to get past a preboot problem. Managed to do that.
The instructions I was given to follow for manually loading LynxOS were x86 based. I am expected to translate that to PPC. In any event, the makeboot -r 0,48 preboot is wrong for this PPC machine. This has caused me to have an unbootable system once again. How does one know what numbers to use for a given system?
Reviewed documentation I've written so far, mostly just Cross LynxOS build. Several suggestions were made and being implemented.
Continue reading "Disk space problems & int_tools checkout" »
Added more structure to the documentation by including things I've developed at home with PHP. Mainly added a menu on the left hand side so as to allow easier navigation of the pages.
After Moscow fixed the atoi error I believe that the TOT build succeeded!
Well I played around with this a little more and came up with a Perl script that will dump ECR descriptions fairly easy. From what I understand that's mostly what we want access to from a Linux box (though I could envision wanting other things perhaps in the future). The problem as I see it is that this script will only run on lynx12. It should be runnable from any machine really however you would need to install the DBD module for Informix for Perl access. Unfortunately this requires at least an Informix Client SDK and that's not free! :-(
The algorithm that files4ecr.pl uses is indeed slow. Combing through lynxos looking for files involved in ECR 20591 took:
real 416m30.889s user 6m43.900s sys 1m42.770s
Yikes!
Here's the plan:
Continue reading "files4ecr.pl/Building TOT as per instructions" »
Continue reading "LOS178 Build/5.0.0 native toolchain build" »