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.

[Olly Betts]

Did you resolve this?

If not, please provide the full config.log and the generated configure script as I requested above.

[Eyal R.]

Attached my config.log (on the Devuan 6 system). I also pulled master again, cleared the BUILD and INST directories, and ran bootstrap and configure again. Same outcome.

[Olly Betts]

Thanks.

Your log actually shows the probe for mode_t succeeding - see ​https://trac.xapian.org/attachment/ticket/826/config.log#L2134

It looks like its first probe for mode_t works (​https://trac.xapian.org/attachment/ticket/826/config.log#L2017) which tries with sizeof(mode_t) but then it tries with sizeof((mode_t)) which fails. That could be optimised to stop when it works, but that's just a slight inefficiency - the overall (and reported) result is that mode_t is found.

Your actual problem is this:

2174	configure:23246: checking for help2man
2175	configure:23284: result: no
2176	configure:23290: error: help2man is required to build documentation 

You need to install help2man to build from git.

Not a bug so closing.

[Olly Betts]

I had a quick dig into the extra compilation with an eye to opening a bug report in autoconf, but actually it's deliberate - towards the end of a long comment discussing the problems with other approaches there's:

# Then you think of using sizeof to make sure the TYPE is really
# defined:
#
#         sizeof (TYPE);
#
# That is great, but has one drawback: it succeeds when TYPE happens
# to be a variable: you'd get the size of the variable's type.
# Obviously, we must not accept a variable in place of a type name.
#
# So, to filter out the last possibility, we will require that this fail:
#
#         sizeof ((TYPE));
#
# This evokes a syntax error when TYPE is a type, but succeeds if TYPE
# is actually a variable.

[Eyal R.]

I'm sorry for the trouble. It was my mistake for failing to notice that part of the log.