29 Oct 2002 johnm   » (Journeyer)

Extreme panic!

Each time I do a full prc-tools build, I get a 1.3 Mb build log and sometimes I even look at it. (Building prc-tools means building two binutilses, two GCCs, a GDB, and a few other bits and pieces. Along the way you build four BFDs and six libiberties. So that log builds up pretty quickly!)

At the moment, due to popular demand (three FreeBSD whiners :-)), I'm working on making --enable-nls work properly. To be sure, there's a bug here in the current top-level prc-tools, and I'm glad to be finally looking into it.

So I'm comparing the logs from builds with and without --with-included-gettext. I look at the differences between successive builds regularly (all hail tkdiff!), but these two (of course) differ from each other in different places from the usual. And there's many more differences to look at than usual, alas.

This means I'm studying different parts of the logs from usual. Here's a few lines from tonight's builds:

gcc -W -Wall -Wstrict-prototypes -Wmissing-prototypes -g -O2 -o size size.o bucomm.o version.o filemode.o ../bfd/.libs/libbfd.a ../libiberty/libiberty.a
bucomm.o: In function `make_tempname':
/home/johnm/work/rpmbuild/BUILD/prc-tools-20020831/m68k-palmos/ binutils/binutils/../../.././binutils/binutils/bucomm.c:236: the use of `mktemp' is dangerous, better use `mkstemp'

Huh? What's that path from the end of August doing there? That build tree is long since blown away -- each one is over half a gigabyte, so I nuke them pretty quickly. So I look at the build logs from the last week, and they all say 20020831, and sure enough that directory certainly hasn't existed for a long time.

What's going on? Has ext3 let me down? Is my hard drive failing again? Is the end nigh?

Panic stations! Single user mode, fsck... no, nothing.

Have you guessed yet? It was ccache.

I last really compiled bucomm.c back in August when I switched ccache on. One of ccache's big features over compilercache is that it doesn't give up in the face of warnings. So that 20020831 directory doesn't really exist; it's just that I'm getting the old stderr log from August. It's hard to see how ccache could correct this without rerunning the compilation or parsing the basic error format and guessing, so it's understandable; on the other hand, the Web page does say

[ccache provides] exactly the same object files and exactly the same compiler warnings that would be produced if you use the real compiler. The only way you should be able to tell that you are using ccache is the speed.

Sure, the speed is great -- ten minutes instead of 40 with my machine on this project -- but I've just learnt one grain of salt to apply to the warning guarantees :-).

Sure, there's other lessons to be learnt here: like don't vary your paths when you're trying to do repeatable builds (but some form of date convention is a useful and commonly used way to stay sane) and don't use absolute paths (but sometimes your tools will make them absolute whether you want it or not).

Anyway. Onward to the next disaster...

Latest blog entries     Older blog entries

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!