Syntax error in conftext.cpp:105 during configure

[Eyal R.]

I'm building the xapian master branch on my machine, a Devuan GNU/Linux 6 Excalibur (equivalent to Debian trixie but without systemd).

After bootstrapping, and during the configure step, I get the following error:

conftest.cpp: In function 'int main()':
| conftest.cpp:105:20: error: expected primary-expression before ')' token
|   105 | if (sizeof ((mode_t)))
|       |                    ^
| configure:22851: $? = 1
| configure: failed program was:
| | /* confdefs.h */

that does indeed look like a syntax error... configuration cannot conclude and I can't build.

My GCC version is 13.2.0, my kernel version is 6.6.13 and my glibc version is 2.37

[Eyal R.]

I also this problem on a machine running SLES 15 SP5.

[Olly Betts]

My GCC version is 13.2.0, my kernel version is 6.6.13 and my glibc version is 2.37

It would be useful to report your Xapian version too...

[Olly Betts]

Ah sorry, "xapian master branch".

The thing is we just use the autoconf-provided AC_TYPE_MODE_T - there are no explicit mentions of mode_t in any of the configure.ac files. I also don't see the problem on Debian unstable.

[Eyal R.]

Replying to Olly Betts:

The thing is we just use the autoconf-provided AC_TYPE_MODE_T - there are no explicit mentions of mode_t in any of the configure.ac files.

The Omega Changelog says:

• configure.ac: Probe for ssize_t and mode_t and define replacements

and I also find:

xapian-applications/omega/configure:ac_fn_cxx_check_type "$LINENO" "mode_t" "ac_cv_type_mode_t" "$ac_includes_default"

I'm not an autoconf expert, so I can't say much more that's useful about this situation.

[Olly Betts]

The Omega Changelog says: [...]

That's from an entry dated 2007. We really would have noticed long ago if this problem was introduced 17 years ago.

We *DO* still probe for mode_t, etc, but as I said we use the standard autoconf-provided macros to do so - that code you quote from configure comes from autoconf, it's not in our repo. However if you follow it through, the test code that gets generated and compiled should only has a single set of parentheses around the type sizeof is applied to - see shell function ac_fn_cxx_check_type:

int
main (void)
{
if (sizeof ($2))
         return 0;
  ;
  return 0;
}

Here $2 is the type being tested, which comes from the code you quote. That passes mode_t not (mode_t), so the test program should have sizeof (mode_t).

The only change we've made in this area at all recently was upgrading to bootstrapping with libtool 2.4.7 on April 2nd, but I don't see any references to mode_t or ac_fn_cxx_check_type in there.

I do most of my dev work on a Debian unstable machine so this looks like some difference in devaun - are they carrying extra patches in their autoconf package perhaps?

You could try running bootstrap with ./bootstrap --download-tools=always to tell it not to even consider using installed versions of autoconf, etc. If that works, that very strongly points the finger at some dodgy distro patching.

[Eyal R.]

You could try running bootstrap with ./bootstrap --download-tools=always to tell it not to even consider using installed versions of autoconf, etc.

Tried that, and it didn't work.

If that works, that very strongly points the finger at some dodgy distro patching.

On two unrelated machines? With very different distributions? That seems unlikely... The SLES15 machine I don't even have root privileges on, it's some machine at work.

[Olly Betts]

Distros do cherry-pick fixes from one another, but you're right that makes this seem less likely. However it's also unlikely that it works for me but fails for you on two very similar distros, and AIUI yours pulls most changes directly from mine.

Perhaps you should post the full config.log and the generated configure script from whichever module you get this failure in (both xapian-core and xapian-omega use AC_TYPE_MODE_T - I suspect it must fail in xapian-core for you since that gets configured first, and if it succeeded in xapian-core then I'd expect xapian-omega to just use the cached result as we set up a shared cache for configure probe results).

Also please give the exact commit hash you are using so I can compare against the exact same state of the tree.