Jay Lee writes:

There's nothing especially outrageous in esmtpclient.c. esmtpclient.c is a rather mild, straightforward bit of code. There one macro in there that's slightly bit longer than the average macro, but nowhere near the atrocious macros you might find somewhere else.

If gcc4 is choking on it, it must be hitting a particularly devious bug.

If you want to investigate this further, and perhaps make a positive contribution to gcc4's development, you might want to start partitioning this file. Chop off the last half of it, at some function boundary, and see what happens. Of course, eventually the compile will break because some code is missing, but the only thing you're looking for is whether gcc4 blows up, on not.

Eventually, you could probably narrow it down to the point where you might have something useful to report.

Of course, given that everything is GPLed you can always dump the entire courier-authlib and courier tarballs on someone's lap, but that might be over the top.

Once you've narrowed things down as much as you could, you need to screw around with the Makefile so you get to see the actual g++ invocation parameters. I've hacked the Makefile so you don't get to see the whole deal, just a "compiling <filename>". The real deal has just so much crap that it hurts my eyes. But here's the exception where you want to see the actual g++ command.

Once you know that, add the -E option, so that you get the post-preprocessed C code, save it, then feed it to g++ again, with the same parameters. If it still crashes, send the file and the command line options to the g++ list.