| View Issue Details [ Jump to Notes ] | [ Print ] | ||||||||
| ID | Project | Category | View Status | Date Submitted | Last Update | ||||
| 0013320 | CMake | CMake | public | 2012-06-19 16:08 | 2012-11-05 14:33 | ||||
| Reporter | Daniel Richard G. | ||||||||
| Assigned To | Brad King | ||||||||
| Priority | normal | Severity | minor | Reproducibility | always | ||||
| Status | closed | Resolution | fixed | ||||||
| Platform | PA-RISC | OS | HP-UX | OS Version | 11.00 | ||||
| Product Version | CMake 2.8.8 | ||||||||
| Target Version | Fixed in Version | ||||||||
| Summary | 0013320: UINT32_C() et al. macro shenanigans break build on HP-UX | ||||||||
| Description | Bootstrapping CMake 2.8.8 on this HP-UX system fails with [ 1%] Building C object Utilities/KWIML/test/CMakeFiles/cmIML_test.dir/test_INT_C.c.o cd /tmp/cmake-build/Utilities/KWIML/test && /opt/tg/bin/tg-gcc -DKWIML_NAMESPACE=cmIML -DKWIML_LANGUAGE_C -DKWIML_LANGUAGE_CXX -pipe -W -Wall -Wcast-align -Wformat=2 -Wpointer-arith -Wundef -mpa-risc-2-0 -O3 -Wno-format -I/tmp/cmake-build/Utilities/KWIML/test -I/tmp/cmake-build/Utilities -o CMakeFiles/cmIML_test.dir/test_INT_C.c.o -c /home/src/cmake-2.8.8/Utilities/KWIML/test/test_INT_C.c In file included from /home/src/cmake-2.8.8/Utilities/KWIML/test/test_INT_C.c:14:0: /tmp/cmake-build/Utilities/KWIML/test/test_INT_format.h: In function 'test_INT_format': /tmp/cmake-build/Utilities/KWIML/test/test_INT_format.h:195:1: error: pasting ")" and "l" does not give a valid preprocessing token /tmp/cmake-build/Utilities/KWIML/test/test_INT_format.h:195:3: error: expected ',' or ';' before 'l' gmake[2]: *** [Utilities/KWIML/test/CMakeFiles/cmIML_test.dir/test_INT_C.c.o] Error 1 gmake[2]: Leaving directory `/tmp/cmake-build' gmake[1]: *** [Utilities/KWIML/test/CMakeFiles/cmIML_test.dir/all] Error 2 gmake[1]: Leaving directory `/tmp/cmake-build' gmake: *** [all] Error 2 The test_INT_format.h makes use of a symbol UINT32_C, and others like it. This is defined in inttypes.h: $ gnu-grep -R UINT32_C /usr/include /usr/include/inttypes.h:#define UINT32_C(__c) __CONCAT_U__(__c) /usr/include/inttypes.h:#define UINT32_C(__c) __CONCAT__(__CONCAT_U__(__c),l) /usr/include/inttypes.h:# define UINT32_MAX UINT32_C(4294967295) From what I can tell, this macro is being expanded before being passed as an argument to TEST_C(). I'm not sure how to work around this. | ||||||||
| Tags | No tags attached. | ||||||||
| Attached Files |  inttypes.h [^] (13,265 bytes) 2012-06-20 11:39 | ||||||||
| Relationships | ||||||
|
||||||
| Relationships |
| Notes | |
|
(0029749) Brad King (manager) 2012-06-19 16:26 |
This change fixed a similar problem on other platforms: http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=f94ae0ec [^] but it is already in 2.8.8. What are the definitions of __CONCAT_U__ and __CONCAT__ ? |
|
(0029750) Daniel Richard G. (reporter) 2012-06-19 16:46 |
Nuts, this issue also comes up in [ 77%] Building C object Source/CMakeFiles/CMakeLib.dir/cm_sha2.c.o cd /tmp/cmake-build/Source && /opt/tg/bin/tg-gcc -DCURL_STATICLIB -DLIBARCHIVE_STATIC -DCMAKE_BUILD_WITH_CMAKE -DCMAKE_USE_NINJA -pipe -W -Wall -Wcast-align -Wformat=2 -Wpointer-arith -Wundef -mpa-risc-2-0 -O3 -I/tmp/cmake-build/Utilities -I/home/src/cmake-2.8.8/Utilities -I/tmp/cmake-build/Source -I/home/src/cmake-2.8.8/Source -I/tmp/cmake-build/Utilities/cmcompress -I/home/src/cmake-2.8.8/Source/CTest -I/home/src/cmake-2.8.8/Source/CursesDialog/form -I/tmp/cmake-build/Source/CursesDialog/form -o CMakeFiles/CMakeLib.dir/cm_sha2.c.o -c /home/src/cmake-2.8.8/Source/cm_sha2.c /home/src/cmake-2.8.8/Source/cm_sha2.c:241:1: error: pasting ")" and "l" does not give a valid preprocessing token /home/src/cmake-2.8.8/Source/cm_sha2.c:241:2: error: expected '}' before 'l' /home/src/cmake-2.8.8/Source/cm_sha2.c:242:1: error: pasting ")" and "l" does not give a valid preprocessing token /home/src/cmake-2.8.8/Source/cm_sha2.c:243:1: error: pasting ")" and "l" does not give a valid preprocessing token /home/src/cmake-2.8.8/Source/cm_sha2.c:244:1: error: pasting ")" and "l" does not give a valid preprocessing token /home/src/cmake-2.8.8/Source/cm_sha2.c:245:1: error: pasting ")" and "l" does not give a valid preprocessing token /home/src/cmake-2.8.8/Source/cm_sha2.c:250:1: error: pasting ")" and "l" does not give a valid preprocessing token /home/src/cmake-2.8.8/Source/cm_sha2.c:250:2: error: expected '}' before 'l' [further errors elided] Anyway, those two macros are defined (in inttypes.h) as #define __CONCAT__(_A,_B) _A ## _B #define __CONCAT_U__(_A) _A ## u |
|
(0029752) Brad King (manager) 2012-06-19 17:15 |
Your grep output reports two UINT32_C definitions in inttypes.h. What are the preprocessor conditions that select one of them? |
|
(0029753) Daniel Richard G. (reporter) 2012-06-19 17:19 |
Seems to be a 32/64-bit thing: #ifdef __LP64__ #define INT32_C(__c) (__c) #define UINT32_C(__c) __CONCAT_U__(__c) #else /* __LP64 */ #define INT32_C(__c) __CONCAT__(__c,l) #define UINT32_C(__c) __CONCAT__(__CONCAT_U__(__c),l) #endif /* __LP64 */ (This HP-UX machine is strictly 32-bit.) |
|
(0029754) Brad King (manager) 2012-06-19 17:19 |
The platforms' concat macro definitions are wrong. They should be something like#define __CONCAT__(_A,_B) __CONCAT_DELAY__(_A,_B) #define __CONCAT_DELAY__(_A,_B) _A ## _B #define __CONCAT_U__(_A) __CONCAT_DELAY_U__(_A) #define __CONCAT_DELAY_U__(_A) _A ## u The delay gives the preprocessor a chance to evaluate its arguments and concatenate their results. Of course we can't change those so we have to work around them. |
|
(0029755) Brad King (manager) 2012-06-19 17:24 |
What preprocessor test can be used to identify this system? We already have some tests like defined(__HP_cc) || defined(__HP_aCC) but this is known to work on newer HP machines so we need a version test. |
|
(0029756) Daniel Richard G. (reporter) 2012-06-19 17:25 |
Indeed, my newer HP-UX system (B.11.23 on Itanium) has #ifdef __LP64__ #define INT32_C(__c) (__c) #define UINT32_C(__c) __CONCAT_U__(__c) #else /* __LP64 */ #define INT32_C(__c) __CONCAT__(__c,l) #define UINT32_C(__c) __CONCAT__(__c,ul) #endif /* __LP64 */ (The __CONCAT* macros are the same.) |
|
(0029757) Brad King (manager) 2012-06-19 17:28 |
Right, so on the old system the code #define UINT32_C(__c) __CONCAT__(__CONCAT_U__(__c),l) tries to concatenate the literal tokens "__CONCAT_U__(__c)" and "l". That is why it complains about ")" and "l". |
|
(0029758) Daniel Richard G. (reporter) 2012-06-19 17:30 |
Good question. "cpp -dM" isn't showing anything particularly apropos: $ cpp -dM empty.h | grep -i hp #define __hppa 1 #define __hpux 1 #define __hp9000s700 1 #define __hp9000s800 1 #define __hp9000s800__ 1 #define __hp9000s700__ 1 #define __hppa__ 1 #define __hpux__ 1 #define _HPUX_SOURCE 1 Don't see much in the system headers, either... |
|
(0029759) Brad King (manager) 2012-06-19 17:34 |
Well, first try building with the patch below and adding "-DcmIML_INT_BROKEN_UINT32_C" to the flags.diff --git a/Utilities/KWIML/INT.h.in b/Utilities/KWIML/INT.h.in index d40edcd..49e9904 100644 --- a/Utilities/KWIML/INT.h.in +++ b/Utilities/KWIML/INT.h.in @@ -534,7 +534,7 @@ An includer may test the following macros after inclusion: #else # define @KWIML@_INT_INT32_C(c) c #endif -#if defined(UINT32_C) +#if defined(UINT32_C) && !defined(@KWIML@_INT_BROKEN_UINT32_C) # define @KWIML@_INT_UINT32_C(c) UINT32_C(c) #else # define @KWIML@_INT_UINT32_C(c) c ## u |
|
(0029761) Daniel Richard G. (reporter) 2012-06-20 08:12 |
I tested with just "#if 0" there, but that was enough to allow the build to complete successfully, addressing the errors in both test_INT_format.h and cm_sha2.c. (So only UINT32_C() is broken; the other type-macros seem to be fine.) |
|
(0029762) Brad King (manager) 2012-06-20 08:23 |
Will something like this identify the broken case uniquely?#if defined(__hpux) && !defined(__HP_cc) && !defined(__HP_aCC) \ && defined(__CONCAT__) && defined(__CONCAT_U__) && !defined(__LP64__) # define @KWIML@_INT_BROKEN_UINT32_C #endif |
|
(0029769) Daniel Richard G. (reporter) 2012-06-20 11:42 |
I would drop the __HP_cc and __HP_aCC bits from that, as this is a system-header thing, not a compiler thing. But I would add defined(__GNUC__), because the HP compiler/cpp can correctly process the broken __CONCAT* macros. I just double-checked this with a trivial program and -E: gcc bombs out, cc gives the right output. I think it should be fine to presume UINT32_C() is broken without regard to the version of HP-UX, as it seems the type-suffix has always been "ul" in the non-64-bit case. Oh, and for reference purposes, I've attached the inttypes.h header with the broken UINT32_C(). (The system is HP-UX B.11.00, according to uname(1).) |
|
(0029771) Brad King (manager) 2012-06-20 11:59 |
Okay, so you propose:#if defined(__hpux) && !defined(__LP64__) && defined(__GNUC__) \ && defined(__CONCAT__) && defined(__CONCAT_U__) /* Old HP defines UINT32_C in a way that breaks GNU. */ # define @KWIML@_INT_BROKEN_UINT32_C #endif However, note that the line using @KWIML@_INT_BROKEN_UINT32_C, shown in 0013320:0029759, falls back to suffix "u", not "ul". With this workaround does the test still pass at runtime? |
|
(0029772) Daniel Richard G. (reporter) 2012-06-20 12:14 |
That conditional looks right to me. But yes, "ul" for uint32_t isn't the norm. I don't suppose it would be kosher to just redefine UINT32_C() in that specific case? Or maybe define XXX_INT_UINT32_C() for HP, and enclose the standard definition in an "#ifndef XXX_INT_UINT32_C"? As for the runtime test, this is what I get from the earlier "#if 0" build: $ ./cmIML_test | grep -v ', PASSED$' C cmIML_INT_SCNi8: expected [-85], got [0], FAILED C cmIML_INT_SCNd8: expected [-85], got [0], FAILED C cmIML_INT_SCNo8: expected [253], got [0], FAILED C cmIML_INT_SCNu8: expected [171], got [0], FAILED C cmIML_INT_SCNx8: expected [ab], got [0], FAILED C cmIML_INT_SCNx8: expected [AB], got [0], FAILED C++ cmIML_INT_SCNi8: expected [-85], got [0], FAILED C++ cmIML_INT_SCNd8: expected [-85], got [0], FAILED C++ cmIML_INT_SCNo8: expected [253], got [0], FAILED C++ cmIML_INT_SCNu8: expected [171], got [0], FAILED C++ cmIML_INT_SCNx8: expected [ab], got [0], FAILED C++ cmIML_INT_SCNx8: expected [AB], got [0], FAILED (New bug report?) |
|
(0029773) Brad King (manager) 2012-06-20 13:00 |
Re 0013320:0029772: It looks like the test for UINT32_C passes with suffix "u" anyway. As for the SCN*8 trouble, let's keep all these related problems for the platform in this issue entry. Several platforms lack support for SCN*8 so we just need to add the condition for this one. |
|
(0029776) Brad King (manager) 2012-06-20 13:27 |
Try this patch for the SCN*8 trouble. Please confirm that the problem is for both the HP and GNU compilers.diff --git a/Utilities/KWIML/INT.h.in b/Utilities/KWIML/INT.h.in index d40edcd..0251f02 100644 --- a/Utilities/KWIML/INT.h.in +++ b/Utilities/KWIML/INT.h.in @@ -259,8 +259,6 @@ An includer may test the following macros after inclusion: # endif #elif defined(__SUNPRO_C) || defined(__SUNPRO_CC) # define @KWIML@_INT__NO_SCN8 -#elif defined(__HP_cc) || defined(__HP_aCC) -# define @KWIML@_INT__NO_SCN8 #elif defined(__BORLANDC__) # define @KWIML@_INT__NO_SCN8 # define @KWIML@_INT__NO_SCN64 @@ -268,6 +266,8 @@ An includer may test the following macros after inclusion: # define @KWIML@_INT__NO_SCN8 #elif defined(__WATCOMC__) # define @KWIML@_INT__NO_SCN8 +# elif defined(__hpux) /* HP runtime lacks support (any compiler) */ +# define @KWIML@_INT__NO_SCN8 #endif /* 8-bit d, i */ |
|
(0029777) Brad King (manager) 2012-06-20 13:52 |
Here is a full patch to try for the UINT32_C problem:
diff --git a/Utilities/KWIML/INT.h.in b/Utilities/KWIML/INT.h.in
index d40edcd..dc34fec 100644
--- a/Utilities/KWIML/INT.h.in
+++ b/Utilities/KWIML/INT.h.in
@@ -91,10 +91,11 @@ An includer may test the following macros after inclusion:
Some compilers define integer format macros incorrectly for their
own formatted print/scan implementations.
- @KWIML@_INT_BROKEN_INT64_C = macro INT64_C is incorrect if defined
- @KWIML@_INT_BROKEN_UINT64_C = macro UINT64_C is incorrect if defined
+ @KWIML@_INT_BROKEN_INT#_C = macro INT#_C is incorrect if defined
+ @KWIML@_INT_BROKEN_UINT#_C = macro UINT#_C is incorrect if defined
Some compilers define integer constant macros incorrectly and
- cannot handle literals as large as the integer type.
+ cannot handle literals as large as the integer type or even
+ produce bad preprocessor syntax.
@KWIML@_INT_BROKEN_INT8_T = type 'int8_t' is available but incorrect
Some compilers have a flag to make 'char' (un)signed but do not account
@@ -341,12 +342,12 @@ An includer may test the following macros after inclusion:
#endif
/* 8-bit constants */
-#if defined(INT8_C)
+#if defined(INT8_C) && !defined(@KWIML@_INT_BROKEN_INT8_C)
# define @KWIML@_INT_INT8_C(c) INT8_C(c)
#else
# define @KWIML@_INT_INT8_C(c) c
#endif
-#if defined(UINT8_C)
+#if defined(UINT8_C) && !defined(@KWIML@_INT_BROKEN_UINT8_C)
# define @KWIML@_INT_UINT8_C(c) UINT8_C(c)
#else
# define @KWIML@_INT_UINT8_C(c) c ## u
@@ -435,12 +436,12 @@ An includer may test the following macros after inclusion:
#endif
/* 16-bit constants */
-#if defined(INT16_C)
+#if defined(INT16_C) && !defined(@KWIML@_INT_BROKEN_INT16_C)
# define @KWIML@_INT_INT16_C(c) INT16_C(c)
#else
# define @KWIML@_INT_INT16_C(c) c
#endif
-#if defined(UINT16_C)
+#if defined(UINT16_C) && !defined(@KWIML@_INT_BROKEN_UINT16_C)
# define @KWIML@_INT_UINT16_C(c) UINT16_C(c)
#else
# define @KWIML@_INT_UINT16_C(c) c ## u
@@ -528,13 +529,19 @@ An includer may test the following macros after inclusion:
# define @KWIML@_INT_PRIX32 "X"
#endif
+#if defined(__hpux) && defined(__GNUC__) && !defined(__LP64__) \
+ && defined(__CONCAT__) && defined(__CONCAT_U__)
+ /* Some HPs define UINT32_C incorrectly and break GNU. */
+# define @KWIML@_INT_BROKEN_UINT32_C
+#endif
+
/* 32-bit constants */
-#if defined(INT32_C)
+#if defined(INT32_C) && !defined(@KWIML@_INT_BROKEN_INT32_C)
# define @KWIML@_INT_INT32_C(c) INT32_C(c)
#else
# define @KWIML@_INT_INT32_C(c) c
#endif
-#if defined(UINT32_C)
+#if defined(UINT32_C) && !defined(@KWIML@_INT_BROKEN_UINT32_C)
# define @KWIML@_INT_UINT32_C(c) UINT32_C(c)
#else
# define @KWIML@_INT_UINT32_C(c) c ## u
|
|
(0029785) Daniel Richard G. (reporter) 2012-06-20 16:14 edited on: 2012-06-21 08:00 |
I see the same SCN*8 failures for both cc- and gcc-built cmIML_test programs, prior to patching. I will report back on test builds with gcc and cc using 2.8.8 plus the patches in 0013320:0029776 , 0013320:0029777 , and 0013321:0029774 . (The cc build, however, won't get very far due to bug 13332.) |
|
(0029791) Daniel Richard G. (reporter) 2012-06-21 01:04 |
The gcc build completes successfully; the cc build stopped at the expected point. Both successfully built cmIML_test, and both binaries no longer produce any FAILED lines. |
|
(0029795) Brad King (manager) 2012-06-21 08:32 edited on: 2012-06-21 08:34 |
Applied UINT32_C fix and SCN*8 fix: http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ec1d3524 [^] http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=539064d4 [^] http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=64d0e156 [^] |
|
(0031458) David Cole (manager) 2012-11-05 14:33 |
Closing resolved issues that have not been updated in more than 4 months. |
| Notes |
| Issue History | |||
| Date Modified | Username | Field | Change |
| 2012-06-19 16:08 | Daniel Richard G. | New Issue | |
| 2012-06-19 16:26 | Brad King | Note Added: 0029749 | |
| 2012-06-19 16:46 | Daniel Richard G. | Note Added: 0029750 | |
| 2012-06-19 17:15 | Brad King | Note Added: 0029752 | |
| 2012-06-19 17:19 | Daniel Richard G. | Note Added: 0029753 | |
| 2012-06-19 17:19 | Brad King | Note Added: 0029754 | |
| 2012-06-19 17:24 | Brad King | Note Added: 0029755 | |
| 2012-06-19 17:25 | Daniel Richard G. | Note Added: 0029756 | |
| 2012-06-19 17:28 | Brad King | Note Added: 0029757 | |
| 2012-06-19 17:30 | Daniel Richard G. | Note Added: 0029758 | |
| 2012-06-19 17:34 | Brad King | Note Added: 0029759 | |
| 2012-06-20 08:12 | Daniel Richard G. | Note Added: 0029761 | |
| 2012-06-20 08:20 | Brad King | Relationship added | related to 0013321 |
| 2012-06-20 08:23 | Brad King | Note Added: 0029762 | |
| 2012-06-20 11:39 | Daniel Richard G. | File Added: inttypes.h | |
| 2012-06-20 11:42 | Daniel Richard G. | Note Added: 0029769 | |
| 2012-06-20 11:59 | Brad King | Note Added: 0029771 | |
| 2012-06-20 12:14 | Daniel Richard G. | Note Added: 0029772 | |
| 2012-06-20 13:00 | Brad King | Note Added: 0029773 | |
| 2012-06-20 13:27 | Brad King | Note Added: 0029776 | |
| 2012-06-20 13:52 | Brad King | Note Added: 0029777 | |
| 2012-06-20 16:14 | Daniel Richard G. | Note Added: 0029785 | |
| 2012-06-20 16:17 | Daniel Richard G. | Note Edited: 0029785 | |
| 2012-06-20 16:18 | Daniel Richard G. | Note Edited: 0029785 | |
| 2012-06-21 01:04 | Daniel Richard G. | Note Added: 0029791 | |
| 2012-06-21 08:00 | Brad King | Note Edited: 0029785 | |
| 2012-06-21 08:32 | Brad King | Note Added: 0029795 | |
| 2012-06-21 08:32 | Brad King | Assigned To | => Brad King |
| 2012-06-21 08:32 | Brad King | Status | new => resolved |
| 2012-06-21 08:32 | Brad King | Resolution | open => fixed |
| 2012-06-21 08:34 | Brad King | Note Edited: 0029795 | |
| 2012-11-05 14:33 | David Cole | Note Added: 0031458 | |
| 2012-11-05 14:33 | David Cole | Status | resolved => closed |
| Issue History |
| Copyright © 2000 - 2018 MantisBT Team |