Configure Fails on OSF/1 (Tru64) on sizeof(wchar_t) Test with Compaq C

[ArmstrongJ]

Version 3.2.1 seems to fail to configure on Tru64 5.1B when using the Compaq C compiler:

checking whether UINTMAX_MAX is declared... no
checking whether SSIZE_MAX is declared... yes
checking whether EFTYPE is declared... yes
checking whether EILSEQ is declared... yes
checking for wchar_t... yes
checking size of wchar_t... configure: error: in '/root/Workspace/libarchive-3.2.1':
configure: error: cannot compute sizeof (wchar_t)
See 'config.log' for more details

The relevant config.log entries seem to suggest issues with some compiler flags:

config.log

Failed tests appear near line 11132 of the linked file.

[jsonn]

This looks like a broken compiler to me. It has wchar_t, but it doesn't provide a size for it?!

[ArmstrongJ]

The following compiles and runs just fine:

#include <stdio.h>
#include <wchar.h>

int main(int argc, char *argv[])
{

        printf("size is %d\n", sizeof(wchar_t));
        return 0;
}

The compiler is fine. As I mentioned, something odd is occurring with compiler flags using Compaq C, which is why I included config.log.

[ArmstrongJ]

The applicable config.log lines:

configure:16369: checking size of wchar_t
configure:16374: cc -o conftest -g -Wall -Wformat -Wformat-security -I/usr/local/include  conftest.c -lxml2 -lbz2 -lz  >&5
ld:
Invalid flag usage: Wall, -Wx,-option must appear after -_SYSTYPE_SVR4 
ld: Usage: ld [options] file [...]
configure:16374: $? = 1

EDIT: Actually, Compaq C seems to fail anytime there is sizeof calculation where the argument appears in an extra set of parentheses. The following all appear in the log file:

configure:15974: cc -c -g -Wall -Wformat -Wformat-security -I/usr/local/include conftest.c >&5
cc: Error: conftest.c, line 113: Invalid expression. (badexpr)
if (sizeof ((unsigned long long)))

configure:16359: cc -c -g -Wall -Wformat -Wformat-security -I/usr/local/include conftest.c >&5
cc: Error: conftest.c, line 129: Invalid expression. (badexpr)
if (sizeof ((wchar_t)))
---------------------^

configure:15750: cc -c -g -Wall -Wformat -Wformat-security -I/usr/local/include conftest.c >&5
cc: Error: conftest.c, line 107: Invalid expression. (badexpr)
if (sizeof ((mode_t)))
--------------------^

configure:15763: cc -c -g -Wall -Wformat -Wformat-security -I/usr/local/include conftest.c >&5
cc: Error: conftest.c, line 107: Invalid expression. (badexpr)
if (sizeof ((off_t)))
-------------------^

configure:15774: cc -c -g -Wall -Wformat -Wformat-security -I/usr/local/include conftest.c >&5
cc: Error: conftest.c, line 107: Invalid expression. (badexpr)
if (sizeof ((size_t)))
--------------------^

etc., etc.

[ArmstrongJ]

I don't know my C standards, but, apparently, the extra parentheses are the issue. The following program:

#include <stdio.h>
#include <wchar.h>

int main(int argc, char *argv[])
{

        printf("size is %d\n", sizeof((wchar_t)));
        return 0;
}

when compiled with the c89 standard in GCC, returns:

$ gcc -o wtest -std=c89 -pedantic -Wall wtest.c
wtest.c: In function ‘main’:
wtest.c:7:48: error: expected expression before ‘)’ token
         printf("size is %d\n", sizeof((wchar_t)));
                                                ^

The above error occurs with GCC 5.3.1 on ARM.

[jsonn]

-std=c89 forces the hiding of wchar_t, so the last is a red hering. Note that ``sizeof(wchar_t)` contains redundant parenthesis already.

But looking at the other tests makes me wonder: does this crappy CC pass down -Wall to the linker, without interpreting it and without otherwise failing on it?! That would explain why this test triggers it, it is the first link test after the check for -Wall support.

[ArmstrongJ]

Sigh... The type wchar_t is not why it's failing in my last example. The following also fails if I test for sizeof((int)):

$ gcc -o wtest -std=c89 -pedantic -Wall wtest.c
wtest.c: In function ‘main’:
wtest.c:7:44: error: expected expression before ‘)’ token
         printf("size is %d\n", sizeof((int)));
                                            ^

GCC reports that something is expected prior to the parentheses closing the sizeof call. The compiler sees a type in parentheses, and a proper expression would involve a typecasting, so sizeof((int)i) is perfectly fine, but sizeof((int)) is missing a variable to typecast, hence the "error: expected expression before ')’ token" message. Compaq C also doesn't like this, reporting "badexpr," or bad expression. I think @jsonn is blaming a relatively good C compiler a bit much.

The question I have now is why does the configure script end up testing the above expression? This situation doesn't occur on Linux; the expression sizeof((wchar_t)) is never tested. Does anyone have any insight with autotools as to why it would behave differently?

I've also tried configuring libarchive 3.1.2 on Tru64, and it works just dandy. The wchar_t tests pass with no problems (the size is 4, by the way). libarchive-3.1.2 fails because of an earlier bug, though, which has since been fixed.

[jsonn]

Most of the discussion is just misleading. The first wchar_t error is expected and not relevant. The real problem remains the #%@#$%#@$% option handling of the compiler. cc -Wall -c foo.c works without hassle according to config.log, but cc -Wall foo.c fails with the linker not understanding -Wall.

[ArmstrongJ]

It appears that 9f6c6d5 broke building on Tru64. Prior to that commit, the compiler flags -Wall -Wformat -Wformat-security were not used during configure tests. The GCC-specific warning flags are not "supported" by Compaq C (it uses a lowercase -w with far fewer options, but it's not important). The -Wx flags are instead being passed to the linker.

The issue with testing if the flags are supported is that Compaq C doesn't actually complain about them. Rather, they are simply passed to the linker if linking is requested (i.e. the -c flag isn't used). Testing for their support makes it appear that they are indeed supported. However, they are not. The configure script, when testing for, as an example, -Wformat, uses the following command:

cc -c -g -Wall -Wformat -I/usr/local/include conftest.c >&5

The above will work fine on Tru64's Compaq C compiler. However, if the test actually tried to link:

cc -g -Wall -Wformat -I/usr/local/include conftest.c >&5

it would fail. I'm not exactly sure the best way to fix this test for a niche platform like Tru64 where the compiler doesn't complain about the flags, just the linker.

[kientzle]

I wonder if we should be using this:

http://www.gnu.org/software/autoconf-archive/ax_cflags_warn_all.html

instead of the current

AX_APPEND_COMPILE_FLAGS([-Wall -Wformat -Wformat-security])

Or maybe we should be using ax_append_link_flags

Could you try some of the above and let us know what works for you?

[ArmstrongJ]

Surprisingly, AX_CFLAGS_WARN_ALL doesn't work on Tru64 properly. It actually selected the Intel compiler flags -warn all rather than the proper Compaq C flags -verbose -w0 -warnprotos. The Intel flags are again accepted by the compiler and passed to the linker when linking is required. It may have broken when Intel-specific support was added (maybe?). I'll try some other things...

I don't think we need any AX_APPEND_LINK_FLAGS changes since linking isn't the problem.

[ArmstrongJ]

If lines 81-82 in ax_cflags_warn_all.m4 is changed from:

  AC_COMPILE_IFELSE([AC_LANG_PROGRAM],
                     [VAR=`echo $ac_arg | sed -e 's,.*% *,,'` ; break])

to:

  AC_LINK_IFELSE([AC_LANG_PROGRAM],
                     [VAR=`echo $ac_arg | sed -e 's,.*% *,,'` ; break])

the proper flags are selected for warnings on at least GNU GCC and Compaq C. The configure script is able to complete sucessfully (and sizeof(wchar_t) is properly reported).

Thank you for the suggestions, @kientzle, they were quite helpful.

[kientzle]

Please file a bug with the autoconf maintainers about this issue and the fix you found:

   http://www.gnu.org/software/autoconf/autoconf.html#bug

[ArmstrongJ]

I've "reported" it, though I've heard no response.