Rebuilding the whole Debian archive using the Open64 compiler

I got bored recently, so I rebuilt the whole Debian archive on one of my machines. To make this not a completely useless excercise, I used the Open64 compiler instead of gcc and created build logs for your perusal.

So what is Open64?

From the Wikipedia page:

Open64 is an open source, state-of-art, optimizing compiler for the Intel IA-64 (Itanium), AMD Opteron and Intel IA-32e architecture. It derives from the SGI compilers for the MIPS R10000 processor. It was released under the GPL in 2000, and now mostly serves as a research platform for compiler and computer architecture research groups. Open64 is licensed under the GPL. Open64 supports Fortran 77/95 and C/C++, as well as the shared memory programming model OpenMP. It can conduct high-quality interprocedural analysis, data flow analysis, data dependence analysis and array region analysis.

Open64 installation

The installation is pretty easy fortunately:

$ wget
$ tar xfvj open64-4.0-src.tar.bz2
$ cd open64-4.0
$ export TOOLROOT=/opt/open64
$ make
$ make install (as root)

I think you need gcc-3.4 (gcc 4.x is not yet supported), and for some odd reason you also need csh as one of the install scripts seems to use it.

It would be nice if someone could package Open64 for Debian, I definately don't have the time to maintain such a huge package (a whole maintainer team would probably be good here).

Rebuilding the Debian archive

There are several possible ways (and tools) to rebuild the Debian archive; I've used pbuilder/cowbuilder with the rebuild scripts from Bastian Venthur, which are now included in pbuilder.

First we need to install the required packages, setup a cowbuilder base chroot, and get the list of packages:

$ apt-get install cowdancer grep-dctrl wget devscripts sudo
$ cowbuilder --create --distribution lenny --basepath /var/cache/pbuilder/testing-base.cow
$ cp -r /usr/share/doc/pbuilder/examples/rebuild .
$ cd rebuild
$ ./getlist lenny

Now we add Open64 into the cowbuilder chroot and fix up the chroot by pointing the gcc/g++ symlinks to Open64:

$ cp -a /opt/open64 /var/cache/pbuilder/testing-base.cow/opt
$ chroot /var/cache/pbuilder/testing-base.cow
$ cd /usr/bin
$ mv gcc gcc.orig
$ ln -s /opt/open64/bin/opencc gcc
$ mv g++ g++.orig
$ ln -s /opt/open64/bin/openCC g++
$ exit

In addition, we set the CC and CXX environment variables to Open64, which will make 90% of all (autoconf-using) packages automatically use Open64. We need a small script for that:

$ cat c.cfg:
export CC="/opt/open64/bin/opencc -m32"
export CXX="/opt/open64/bin/openCC -m32"

Now edit the buildall script. Change the Debian mirror used there (optional) and make it use our c.cfg script by adding the --configfile /path/to/rebuild/c.cfg option in the "pdebuild" line.

We can now finally start building the archive:

./buildall list.lenny.i386 lenny

You can also run multiple buildall instances at once to speed up the archive rebuild on SMP/multicore machines, and you can even abort the command and simply restart it later. The script will continue where it left off.


The whole rebuild (with 2 instances of buildall running at the same time) took ca. 9 days on an AMD64 Athlon64 X2 (dual core, 1.8 GHz each) machine with 1 GB of RAM.

I really should have used something like apt-proxy to speed up the rebuild and save some bandwidth, but I read about apt-proxy too late...

All log files from my rebuild are available for detailed analysis if anybody is interested (you can browse the logfiles online or download all of them as tarball). I didn't perform any detailed analysis, just some rough numbers here:

  • Succeeded package builds: 8425
  • Failed package builds: 2509
  • Total number of packages rebuilt: 10934

If anybody does some more elaborate analysis, please let me know.


Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Not as root, please.

Don't build as root, please. su to an unprivileged user and use fakeroot. Or, if fakeroot doesn't work on your platform, tell dpkg-buildpackage to use sudo, like some of the buildds do. (This is why Subversion failed.)


Good point, I'll try to use fakeroot next time.


Log analysis

I did some analysis and am down to 484 logs unanalysed. Here's the script I used and its output:

1077 cases seem to be due to build environment: these need to be retried.
674 E: cannot find ./debian dir
116 E: could not satisfy build-dependency
161 Failed to fetch 404 Not Found
126 dpkg: dependency problems prevent configuration of cdeboostrap

87 cases say ia64 does not appear in control file. 105 cases fail for udeb. These could be improved in rebuild script.

207 cases of autoconf confused by "cross compiling":
116 configure: error: cannot run test program while cross compiling
62 configure: error: cannot check for file existence when cross compiling
29 configure: error: cannot check setpgrp when cross compiling

Google search suggests that 105 cases of "undefined reference to rpl_malloc" is also cross-compile related.

118 cases of imake dumping core. What is this?

96 cases of Java problems:
21 Unable to find a javac compiler
75 The type java.lang.Object cannot be resolved

123 cases of apparently Open64 specific problems; even asking to report the problem!
58 opencc ERROR parsing ... unknown flag
65 Please report this problem to


Great, thanks a lot for the script and your analysis!

Apart from some false positives and 404 errors, the interesting issues are the Open64 specific problems. They will probably either hint at Open64 bugs (or gcc incompatibilities) or at not-too-portable packages.

I'll try to post a list of those bugs to the Open64 devel mailing list so the people there can have a look at them...

Thanks, Uwe.

Compiler errors

I looked through the build logs today and reported all new compiler
errors to the Open64 bug tracker. They are:

  • Bug 407: cannot find address of array, during Writing WHIRL file phase
  • Bug 408: Expand_Neg: unknown mtype, Assertion failure at line 1601 of ../../be/cg/x8664/expand.cxx
  • Bug 409: no register is available for a pre-allocated tn, ../../be/cg/lra.cxx
  • Bug 410: Asm constraint requires x87 implementation
  • Bug 411: WGEN_Expand_Expr: write target is NULL
  • Bug 412: Error: bad register name `%sil'


Great, thanks a lot!


Possible cause

Just picked a random package (libcdio) and saw that it failed with:

checking bitfield ordering in structs... configure: error: cannot run test program while cross compiling

That can be traced to this:

checking build system type... i486-pc-linux-gnu
checking host system type... ia64-unknown-linux-gnu

libbonobo fails with the same reason. although I don't know why it's happening

java stuff fails because the rt.jar or something like that is missing (can't find java.lang.Object)

And there are other random failures regarding the environment (404 errors, directory problems, etc)

I'm pretty sure this can be improved with a little tweaking


Thanks for the comment! The cross-compile issues seem to be a common problem, and the 404 stuff is my fault, I should really use apt-proxy or something instead of plain network access.

The ia64 issue should be investigated, I guess I was missing an open64 compile switch or something.


running this again later?


Do you have any plans of doing this rebuild again some time in the future as fixed packages come in?



Yes, I guess I'll re-run the build one more time with a bunch of fixes in my setup, but I won't do regular builds on my private machine.

It would be good to have/use some project QA infrastructure to do this regularly (similar to lintian/piuparts runs etc.) for all packages.


A bunch of packages

A bunch of packages (including zlib) seemed to have failed because the script that was supposed to download the source package got confused. For example, the log for zlib says that it died because it couldn't download

(this is from

same thing for multitail

MultiTail also failes because of that .dsc-file missing.

false positives

Interesting study.

However, simply looking at the few packages I maintain shows two classes of false positives: the source-URL bug that Mark mentioned, which also affected goo, and outright compiler bugs. (Open64 somehow managed to produce bad assembly from valid pure-C code in ncbi-tools6.) I must own up to one real bug, though: fltk1.1's debian/rules doesn't cope with multi-word ${CC} and ${CXX} settings.

Compiler bugs

The source URL issue will be fixed next time, it was a problem in my setup, not something which is generally broken.

The compiler bugs, however, are the really interesting cases! For one, we can help improve the quality of the compiler by reporting/fixing bugs, and we can also find bugs or portability issues in random Debian packages which should be fixed...

It would be really nice to have this sort of thing run regularly on all packages.

Btw, shall I file a bug for fltk1.1 or do you take care of fixing that (seems you're the maintainer)?

Cheers, Uwe.