Compile Problems

From RockWiki

Jump to: navigation, search

Contents

Find the problem

If your package build fails, ROCK will give you a lot of information as to why it failed; and probably even some information on how to fix it.

Check the logfiles first

First check the logfiles and collect some information from them. Most of the time it is possible to find at least the symptoms of the problem in there, sometimes even the reason and ways to fix them. ROCK creates a logfile for each package that was built in the build directory.

Example listing with some logfiles: 

root@steven:/rock/trunk# ls build/Workstation-2.1.0-DEV-x86-pentium4-32-generic-expert/var/adm/logs/

1-00-dirtree.log  1-gcc34.log              1-net-tools.log
1-autoconf.log    1-gettext.log            1-patch.log
1-bash2.log       1-glibc23.log            1-readline.log
1-binutils.log    1-grep.log               1-sed.log
1-bison.log       1-gzip.log               1-strace.log
1-bzip2.log       1-iproute2.log           1-sysfiles.log
1-coreutils.log   1-linux26-header.log     1-sysvinit.log
1-curl.log        1-m4.log                 1-tar.log
1-diffutils.log   1-make.log               1-texinfo.log
1-e2fsprogs.log   1-mine.log               1-time.log
1-findutils.log   1-mktemp.log             1-util-linux.log
1-flex.log        1-module-init-tools.log  1-wget.log
1-gawk.log        1-modutils.log           1-zlib.log

The name of the logfile is made from three parts:

  • the stage

this is the number at the beginning of the name. Possible values: 0 1 2 3 4 5 6 7 8 9

  • the package name

this is the text following the '-' up to the '.'

  • the type

this is the text after the '.'. Possible values:

    • log
      This indicates that the package built without problems
    • err
      This indicates that the package build failed
    • out
      This indicates that the package build is currently running

In the case of a package build failing, the directory in which it was compiled will not be automatically deleted.

The build environment

If a package couldn't be built the build process will stop or go to the next package. The package which couldn't be build will stay unpacked in your ROCK directory. From within this directory you can recreate the exact build environment used for building the package and trace the error and try possible fixes using the provided debug.sh script.

Example: 

root@steven:/rock/trunk# cd src.groff.1102042146.31669.1318224153
root@steven:/rock/trunk/src.groff.1102042146.31669.1318224153# ./debug.sh
debug-groff:[src.groff.1102042146.31669.1318224153]# cd groff-1.19/
debug-groff:[groff-1.19]# make clean
  ...
  ...
debug-groff:[groff-1.19]# make ${makeopt}
  ...
  ...
/src.groff.1102043871.11331.2912868266/groff-1.19/font -F/ROCK/src.groff.1102043871.11331.2912868266/groff-1.19/font -Upet -ww -Tps -ms -mwww >pic.ps
/ROCK/src.groff.1102043871.11331.2912868266/groff-1.19/src/roff/groff/groff: pic: Segmentation fault (core dumped)
<standard input>:432: warning: closing delimiter does not match
:0: macro error: diversion open while ejecting page (recovering)
make[2]: *** [pic.ps] Error 2
make[2]: Leaving directory `/ROCK/src.groff.1102043871.11331.2912868266/groff-1.19/doc'
make[1]: *** [doc] Error 2
make[1]: Leaving directory `/ROCK/src.groff.1102043871.11331.2912868266/groff-1.19'
make: *** [all] Error 2
debug-groff:[groff-1.19]#

In this case a segmentation fault caused the problem. Segmentation faults can have several reasons, most commonly by overoptimisation. It is possible to disable such optimisation in the compiler.

The CmdWrapper 

This entry is or will soon be deprecated!
Do not rely on its information and ask for more recent information on the Mailing Lists

The CmdWrapper is something unknown (for the guy who wrote this page here). The cmd_wrapper will add and delete some parameter for the compiler and do some more stuff.

The cmd_wrapper.log logfile includes some gcc commands which were changed from the wrapper to add some options (i.e. optimation). To check if some optimation where disabled or enabled look in this file.

sample: this is a part of the cmd_wrapper.log file 

/ROCK/src.groff.1102043871.11331.2912868266/groff-1.19:
- gcc-34 -o conftest conftest.c
+ gcc-34 -Os -pipe -march=pentium4 -o conftest conftest.c -s

Solve the Problem

Make the changes on the package

After the problem is found you can fix it in the package. All changes must be done in the package directory. Changes in the src.packagename tree won't fix the problem.

The problem above were caused by overoptimisation. To change that we can use the CmdWrapper.

For every package there are two files in the rock-src/package/repository/* package.conf and package.desc.

To delete one parameter passed to the GCC we need one line at the end of the package.conf file:

Example: delete -march=* parameter 

var_remove GCC3_WRAPPER_INSERT '-march=[^ ]*'

A better documentation about the variables you will find in the CmdWrapper documentation.

Cleanup and build again

Cleaning the build of broken packages can be done with the 

./scripts/Cleanup

command.

Rebuilding only the package which had the problem can be done with the 

./scripts/Build-Target -cfg <config> -job <jobname>

command. Where the jobname is always stage-package. In our example it would be 3-groff. If build finished without an error you can continue with the next broken package or delete all error logs with the 

./script/Create-ErrList -cfg <config> -delete

command.

Retrieved from "http://www.rocklinux.org/wiki/Compile_Problems"
Personal tools