Martin Michlmayr
Martin Michlmayr

I'm a member of Debian, and I work for HP as an Open Source Community Expert. The opinions expressed here are mine.

Subscribe to the RSS feed of this journal.

Tracking GCC 4.4 related build errors

I started building the Debian archive with GCC 4.4 ten days ago to report build errors. I've completed the archive build now and reported about 220 bugs (the majority with patches). There are roughly 30 build failures left that I haven't analyzed yet. There are also about 35 packages that fail because the boost headers don't work with GCC 4.4. I'll try to build them when the boost headers get fixed.

The majority of GCC 4.4 build errors are trivial. The large majority of failures is because of missing #include statements. There are also about 20 build errors because of improved preprocessor checks.

I'll try to do another archive build when the gcc-4.4 package is in Debian.

Mon, 17 Nov 2008; 19:19 — gccpermanent link

GCC 4.4 related build problems: missing #include

C++ header dependencies got cleaned up in GCC 4.3, which broke a lot of code which relied on headers to be included indirectly through some other headers. I found some new build failures with GCC 4.4 related to missing #includes; in particular, #include <cstdio> is missing in a lot of code.

Typical errors look like these:

error: 'sscanf' was not declared in this scope
error: 'EOF' was not declared in this scope
error: '::fseek' has not been declared
error: 'uint32_t' does not name a type

Below is a table showing which header needs to be included for a number of common functions:

Functions and definesHeader
fopen, fwrite, fclosecstdio
fread, fseek, feofcstdio
sscanf, sprintfcstdio
rename, opencstdio
EOFcstdio
memset, memcpy, strdupcstring
va_listcstdarg
int16_t, uint32_tstdint.h
Mon, 10 Nov 2008; 19:21 — gccpermanent link

GCC 4.4 and better preprocessor checks

GCC 4.4 will show more preprocessor errors when compiling code, partly because some new checks have been added and partly because the full preprocessor directives are now checked. So let's review some common problems. Let's take some code like this:

#ifdef A
#elif
#endif

This will now give:

t.c:2:6: error: #elif with no expression

The reason is that an #elif always needs an argument. Looking at the code, it's obvious that a #else should be used.

Another common issue is this one:

#define B
#ifdef A
#elif B
#endif

The problem here is that you're trying to check whether B is defined, so the third line has to be:

#elif defined(B)

Finally, the following code:

#ifdef A
#elif define(B)
#endif

will give:

t.c:2:13: error: missing binary operator before token "("

It took me a minute to see what was wrong with the code... but define is a typo and what you really want is defined.

Sun, 09 Nov 2008; 15:36 — gccpermanent link

Status of GCC 4.4 on Debian

I started testing GCC 4.4 ten days ago and the results are in. In total, I filed 28 new bugs and ran into 7 known issues. More than half of the bugs I filed have already been fixed and many of those that are still open have already received some attention (debugging, suggested patches). I sent a complete report to the GCC list, although I forgot to mention that I set optimization to -O3 to catch more problems.

I know that it's quite popular to complain about GCC, but I'd say that most impressions people have about the GCC community no longer hold true. The GCC community is very active these days, bugs tend to get a lot of attention and there are major infrastructure changes underway to improve the compiler.

Sat, 13 Sep 2008; 17:31 — gccpermanent link

Starting to test GCC 4.4

I've been too busy to follow GCC development recently and haven't done any testing of development snapshots during the GCC 4.4 development phase so far. However, GCC 4.4 moved to stage 3 yesterday, the development stage dedicated to bug fixes and documentation. Given that GCC is now in stage 3 and that Debian unstable has fairly little churn because of the freeze, it's an ideal time to do some archive rebuilds.

I started archive rebuilds on amd64 and powerpc last night and added ia64 today. I also tried to build GCC on armel, alpha and sparc but there are compiler errors during bootstrap. mips builds fine but I haven't started any archive rebuilds.

I found and reported 9 compiler errors so far. Most of them have already received some attention and one of them has been fixed in the meantime. I'm not looking at build failures of packages at the moment since that's very time consuming and I'm not sure whether I'll find the time to report build failures later as GCC becomes more stable, but we'll see.

Wed, 03 Sep 2008; 21:15 — gccpermanent link

GCC 4.3 porting guide

Benjamin Kosnik of Red Hat put together a guide on the GCC web site with information on porting applications to the upcoming GCC 4.3 release. He integrated some information from my blog and added a number of new items. If you run into any issues while moving to GCC 4.3, I suggest you consult this guide.

Wed, 23 Jan 2008; 20:48 — gccpermanent link

GCC 4.3 related build problems: duplicate function parameters

GCC 4.3 now prints an error message when C++ code contains duplicate function parameter names in function prototypes. You'd think that's a pretty obvious problem, but we still have about 15 packages in the archive that contain such code.

Anyway, for code like this:

class foo {
    foo(int w, int w);
};

GCC will as of 4.3 show the following error message:

t.cc:2: error: multiple parameters named 'w'
Fri, 07 Dec 2007; 21:04 — gccpermanent link

GCC 4.3 related build problems: pedantic preprocessor warnings in C++

Update: This change has been reverted from 4.3 again and won't be in the final release of 4.3.

GCC 4.3 changed pedantic preprocessor warnings in C++ code into errors, in line with the C++ front-end. Because of this change, preprocessor warnings are now errors.

This change has caused at least the twofollowing errors which are all fairly common:

error: "xxx" redefined

It's not allowed to #define something twice, as in this example:

#define TEST "foo"
#define TEST "bar"

This code will lead to the following error:

test2.cc:2:1: error: "TEST" redefined
test2.cc:1:1: error: this is the location of the previous definition

Most typically, this occurs because something is defined in a header that is included and then redefined in the current source file. It can also happen when a #define is put in the code but also on the command line, e.g. via -DTEST="bar". This will lead to:

test2.cc:1:1: error: "TEST" redefined
<command line>:1:1: error: this is the location of the previous definition

The correct solution is to avoid redefinitions directly or to use #ifndef to make sure that something has not been defined already.

extra tokens at end of #endif directive

While an #ifdef obviously needs a second parameter, it's not allowed to give one to #else and #endif. Unfortunately, this is commonly done as a reminder for what is being tested for:

#ifdef TEST
#endif TEST

This code will lead to the following error:

test3.cc:2:8: error: extra tokens at end of #endif directive
Fri, 11 May 2007; 14:37 — gccpermanent link

GCC 4.3 related build problems: missing #include

In GCC 4.3 the C++ header dependencies have been cleaned up. In the past, compilation would often be quite slow because including a simple header would indirectly include a lot of other headers, even if they were not needed to compile the current code. Many headers have now been cleaned up with the result that compilation is quicker. The downside is that programmers cannot rely on indirect inclusion of headers they may need anymore. Instead, everything that is needed has to be directly referenced with an #include.

Typical errors look like these:

error: 'find' is not a member of 'std'
error: 'exit' was not declared in this scope

Below is a table showing which header needs to be included for a number of common functions:

Functions and definesHeader
find, for_each, sortalgorithm
isalnum, touppercctype
INT_MIN, RAND_MAXclimits
printfcstdio
atoi, free, randcstdlib
EXIT_FAILUREcstdlib
strcmp, memcpycstring
auto_ptrmemory
fd_set, mode_tsys/types.h
typeidtypeinfo
Thu, 10 May 2007; 15:56 — gccpermanent link

GCC 4.3: common build failures

Even though GCC 4.2 has seen many delays and still hasn't been released (although it's finally getting close), a lot of development has already been done on trunk for the release of GCC 4.3. I started testing 4.3 in March and in addition to finding and reporting compiler issues I have filed bugs on packages that fail to build with GCC 4.3. The idea is to give people an advance warning and to be ready for GCC 4.3 when it will be released.

We have almost 500 bugs related to GCC 4.3 already, mostly due to a clean-up of C++ headers in GCC that has exposed sloppy programming in many programs. Fortunately, these bugs are easy to fix. As I'm finding common mistakes in packages, I will document these problems and way to make sure a program is ready for GCC 4.3.

Common problems

Update: there is now a GCC 4.3 porting guide that describes the most common problems people will face when moving to GCC 4.3.

Thu, 10 May 2007; 14:48 — gccpermanent link