Broadcom uses CentOS 6.2 source code RPMs as the basis for its binary RPM packages. If additional RPMs are to be added, then it is recommended that CentOS 6.2 source packages be used as the basis as this will avoid any complications with dependencies on existing packages. The CentOS 6.2 source repository can be accessed at http://vault.centos.org/6.2/os/Source/SPackages/.
The steps below highlight how to add an RPM to the build process. These steps assume that the RPM is named <package>.rpm.
- Install the package source code:
rpm -i \<package\>.src.rpm
. This creates the <package>.spec file in the SPEC directory, and adds the package source code to the SOURCES directory.
- Edit the rpms.<toolchain>.<cpu>-<version>/Makefile.arch file and add <package> to the ADDL_RPM_PKGS variable. Good practice is to add it to the end. However if you are adding this package so that it can be used by the builds of existing packages, then you would not add it to the end.
- Edit the rpms.<toolchain>.<cpu>-<version>/src/tools/crtarget.sh file. Towards the end of this file, duplicate one of the lines that installs the package into the fake root. Your new install_rpm line should be added in the same location relative to where <package> was add to ADDL_RPM_PKGS above. Note that you should install <package>.rpm and <package>-devel.rpm if it is available. Other rpm files that are part of the package may also be required.
Updating New RPMs for Broadcom Linux Compilation
The tasks involved in updating a new RPM for compilation for Broadcom Linux can vary widely depending on the techniques used in the <package>.spec file to create the RPM. Typical changes are listed below. Note that in some cases a patch file must be created to patch the CentOS supplied source code. See further information on the patching procedure see the section on Creating Patch Files.
- Always update the "Release" field in the spec file so that it includes a Broadcom specific numeral, starting at value 1. For example, if the existing "Release: " value is "29%{?dist}" then we update it to "29.1%{?dist}" to indicate this is the first revision of the Broadcom package changes.
- Make sure that all libraries are placed in %{_libdir} and not in /lib or /usr/lib. A lot of packages will attempt to put libraries in /lib or /usr/lib, but these locations are not persistent on a Broadcom Linux switch. Instead we need all libraries to be placed in /mnt/fastpath/usr/lib, which is the value of %{_libdir}. Likewise we need to place binaries in /mnt/fastpath/usr/bin, which is the value of %{_bindir}. Making these changes can require modifications to the %files section as well as the way the package is configured, built and installed. Failure to do this can result in the package not installing on the switch with an error about not enough space being available.
- Update the first %files line so that it includes "-f rpm-bin.files". The rpm-bin.files file is created as part of the Broadcom RPM build process, and is a list of files that the crlinks.sh script created in /bin. By default the crlinks.sh script from rpms.<toolchain>.<cpu>-<version>/src/tools is run on the BUILDROOT directory before the RPM is packaged up. It is also run at boot time on the switch. This is done since some things rely on binaries being in /bin, e.g. most shell scripts include lines like "\#! /bin/bash" that require /bin/bash exist for them to run. Note that if there are multiple files sections and anything other than the first has binary files then "-f rpm-bin.files" will not work. Instead the binary files must be explicitly called out by editing the files list.
- Remove any %check section. The %check section cannot be used since this is a cross compile.
- Check the %configure line and look for packages that are not supported on the switch, e.g. selinux.
- Some packages explicitly use gcc as the compiler. Change this to use $TOOLS_PREFIX-gcc or %{__cc}.
- If a compilation fails due to PATH_MAX not being defined then this is typically because the package is assuming that <limits.h> includes <linux/limits.h>. This is not true for Broadcom Linux, and you must include <linux/limits.h> explicitly. The same is true for LOGIN_MAX that needs a <bits/posix2_lim.h> include.
- If configure fails with an error about not being able to perform a check while cross compiling then research into either adding an "export
ac_cv_func_*=yes" type line to your spec file, or edit the configure script (or configure.in / configure.ac) so that it does not attempt the check and instead hard code the result. Web searches have a vast amount of tips and information in this area.
- Although the Makefiles use techniques to overwrite the standard compiler names and compile time flags, some packages work in unique ways and require further modification. For example, some packages use lines such as "export
CC_FLAGS="$RPM_OPT_FLAGS -fpie" and do not use $CFLAGS directly. Since it is the $CFLAGS variable where we set extra compile flags, we need to inject this into the build by using "export CC_FLAGS="$RPM_OPT_FLAGS -fpie $CFLAGS" in the spec file. If your compile is failing due to header files or libraries not being found then check that the right compiler flags are being used, like those described in the Testing the fake root section above.
- If the compilation of the packages fails with a message like "libssh-devel required" then install the missing package on the build machine. You should also update the inst-build-pkgs.sh script to include this package.
- If the installation of an RPM fails with dependency errors then you need to look into bringing those other packages into the build, or compiling the new module such that it does not use them (by modifying the %configure command line), or correct the position of the RPM install in crtargets.sh.
If you compare the spec files for packages supplied by Broadcom to those available in the CentOS vault then you will see the types of changes that are described above.
Creating RPM Patch Files
If you need to change a source code file from a package then you should do so using a patch. For example, suppose you want to make some modifications to file.c which is in the mydir directory of the mynewpackage-1.2 package:
- Copy file.c to file.c.cross and make your modifications to file.c.cross. All source files are located in BUILD/mynewpackage-1.2.
- From the BUILD directory, execute `diff -up mynewpackage-1.2/mydir/file.c mynewpackage-1.2/mydir/file.c.cross > ../SOURCES/mynewpackage-cross.patch`.
- Edit the mynewpackage.spec file and add mynewpackage-cross.patch as a new patch. Typically this means adding new "PatchNN: mynewpackage-cross.patch" and "%patchNN -p1 -b .cross" lines.
Note that you can build up changes to multiple files in the single mynewpackage-cross.patch file by concatenating new diff output to the end of the file.
If you make a mistake and need to make subsequent changes then be careful that the files in BUILD are those with as many patches applied as possible. In some cases in order to get a clean file.c to compare against you have to comment out the "%patchNN" line and start the build again.