"../../glib/glibmm/fileutils.h:437: error: expected initializer before '&' token" is this:

int mkstemp(std::string& filename_template);

and "fileutils.cc:136: error: expected initializer before '&' token" is this:

int mkstemp(std::string& filename_template)

So, I guess that maybe mkstemp is #defined as something. Could you check that by trying to rename that function, please?

However, I wonder why I don't have this problem. I'm using Ubuntu Edgy with this g++ version:
murrayc@ubuntumurrayc:~/svn/gnome218/glibmm$ g++ --version
g++ (GCC) 4.1.2 20060928 (prerelease) (Ubuntu 4.1.1-13ubuntu5)


I guess you are using Ubuntu Feisty. Is that correct?

It should be safe to simply #undef mkstemp if necessary.  If I remember correctly, the C standard allows most of the library functions to be actually macros, but also requires that they still work if #undef'ined.  Well, at least I hope that this applies to mkstemp, too.

- fileutils.h ------------------------------------------------------------------

/** Opens a temporary file.
 * @ingroup FileUtils
 * See the %mkstemp() documentation on most UNIX-like systems. This is a
 * portability wrapper, which simply calls %mkstemp() on systems that have
 * it, and implements it in GLib otherwise.
 * @param filename_template A string that should match the rules for
 *   %mkstemp(), i.e. end in <tt>"XXXXXX"</tt>. The <tt>X</tt> string
 *   will be modified to form the name of a file that didn't exist.
 * @return A file handle (as from open()) to the file opened for reading
 *   and writing. The file is opened in binary mode on platforms where there
 *   is a difference. The file handle should be closed with close(). In
 *   case of errors, <tt>-1</tt> is returned.
 */
int std::string& filename_templateNUN4pa;

-- fileutils.cc ----------------------------------------------------------------

int std::string& filename_templatenjCT11

--------------------------------------------------------------------------------

two return values, and no (), and jumbled function names.

I see the files are generated by gtkmmproc, so my gtkmmproc must be bugged. But I don't seem to have the program gtkmmproc on my computer.

Yes Murray, Ubuntu Feisty.

Craig, I'm not sure what you are trying to tell us with that first chunk of (strange) code.

gtkmmproc is now called gmmproc, but you should never need to execute it directly. Just changing the .hg and .ccg files and running make again should regenerate the files. You might need to run autogen.sh.

Daniel wrote:
> It should be safe to simply #undef mkstemp if necessary

I'd rather not do that in a public header. I think we'll need to check for it in configure to #ifdef it out when necessary. And we'll have to add an alternative method.

Sorry. The code is what gmmproc generated on my computer. The code is obviously wrong. gmmproc must have a bug that causes it to generate this bad code.

Okay, I reproduced the problem on debian unstable, and thanks to Daniel Elstner, I have commited a fix in changeset #371 to svn trunk.

The problem is that m4 version 1.4.8 (the one in debian-unstable, maybe the same as in ubuntu Feisty) recognize mkstemp as a builtin macro. That is why the declaration int mkstemp(std::string& filename_template) gets expanded into int std::string& filename_templateNUN4pa;


So the fix was just to prefix the mkstemp macro by m4_ using the _PREFIX_BUILTIN macro, in tools/m4/base.m4.

I hope this does not break glibmm on pre 1.4.8 versions of m4.

Don't worry, it most surely won't.  Could you please apply the fix to the previous branches, too?  Hmm, let's say to 2.8 and 2.10.  Thanks heaps.

Okay, will do. I'll update this bug when it's done.

Okay, I have applied the patch to 2.8, 2.10 and 2.12.

The current changes in trunk seem to have fixed the problem for me.

Well done. Smart thinking.