Compilation of 4.2p1 fails on Tru64 Unix 4.0f platform with the following configuration settings in use: Host: alpha-dec-osf4.0f Compiler: cc -std1 Compiler flags: -g Preprocessor flags: -I/usr/local/ssl/include Linker flags: -L/usr/local/ssl/lib Libraries: -lcrypto -lrt -lz -lsecurity -ldb -lm -laud Compilation fails with: cc: Error: strtonum.c, line 55: In this statement, "ldLL" is not declared. (undeclared) else if ((ll == LLONG_MIN && errno == ERANGE) || ll < minval) --------------------------------^ *** Exit 1 Stop. *** Exit 1 Stop.
Created attachment 996 [details] Compilation log for 4.2p1 under Tru 64 Unix 4.0f This is the compilation log for 4.2p1 under Tru64 Unix 4.0f
Created attachment 997 [details] Test fragment for LLONG_MIN and LLONG_MAX from configure.ac Take a look in config.h and search for LLONG_MIN and LLONG_MAX. I think that configure is calculating the values but your printf doesn't usderstand "%lld" format. You can compile and run this test program to confirm. It should produce output something like: Calculating LLONG_MIN and LLONG_MAX -9223372036854775808 9223372036854775807 As a quick fix, you can calculate the values of LLONG_MIN and LLONG_MAX by hand and edit config.h with those values.
Compiling and running the test fragment under Tru 64 4.0f produces the following output: Calculating LLONG_MIN and LLONG_MAX ld ld Oddly(?), compiling and running the test fragment on another box under Tru 64 5.1 produces the following output (as expected): Calculating LLONG_MIN and LLONG_MAX -9223372036854775808 9223372036854775807 Manually editing config.h with explicit values for LLONG_MIN and LLONG_MAX on the Tru 64 4.0f box produced a "clean" compilation.
(In reply to comment #3) > Compiling and running the test fragment under Tru 64 4.0f produces the > following output: > Calculating LLONG_MIN and LLONG_MAX > ld ld Sounds like your compiler has long longs but snprintf in libc doesn't understand understand them ("%lld"). > Oddly(?), compiling and running the test fragment on another box under Tru 64 > 5.1 produces the following output (as expected) [...] 5.1 would have a newer libc which would explain it. Perhaps we could add a special case in the test for this. Could you please run "make survey", make sure the "survey" file doesn't contain anything you consider sensitive then attach the file to this bug? Hopefully there will be suitable definitions there to special-case this without further contortions in configure or having people hand-fixing config.h (it's not like people still running 4.0f need extra challenges :-)
Created attachment 1003 [details] survey
Created attachment 1006 [details] relocate llong_max test and add Tru64-specific test The attached patch attempts to work around this. If you apply it you will need to rerun autoconf to rebuild configure. I will attach a configure rebuilt with the patch in case you can't conveniently rebuild it, in which case just replace the configure in the 4.2p1 tarball with it.
Created attachment 1007 [details] configure.gz: configure from 4.2p1 rebuilt with patch id #1006
Created attachment 1008 [details] corrected syntax error in patch
Created attachment 1009 [details] configure.gz: configure from 4.2p1 rebuilt with patch id #1008
Built and installed 4.2p1 source OK with reworked configure script. Thanks for the quick turn-around on this problem!
Change all RESOLVED bug to CLOSED with the exception of the ones fixed post-4.4.