Bug 22572

I've tried to compile every single release version from SystemTap 1.7 to 3.2. 
From 1.7 to 2.9 it compiles ok. The issue seems to be from 3.0 on (basically, 3.0, 3.1 and 3.2).

You might want to try with gcc 4.8 or higher to get full C++11 support.
gcc 4.7 is more than 5 years old now.

(In reply to Gustavo Moreira from comment #1)
> I've tried to compile every single release version from SystemTap 1.7 to
> 3.2. 
> From 1.7 to 2.9 it compiles ok. The issue seems to be from 3.0 on
> (basically, 3.0, 3.1 and 3.2).

According to the NEWS file:

====
* What's new in version 3.1, 2017-02-17

- Systemtap now needs C++11 to build.
====

The configure script tries to check for C++11 support, by seeing if your compiler supports the '-std=c++0x' option. In your config.log file, what is HAVE_CXX11 set to?

Just a guess - does this hypothetical patch fix your build?

diff --git a/staptree.h b/staptree.h
index a376a436b88b..84d4fec63db9 100644
--- a/staptree.h
+++ b/staptree.h
@@ -518,10 +518,10 @@ struct print_format: public expression
     unsigned base;
     unsigned width;
     unsigned precision;
-    unsigned flags : 8;
-    width_type widthtype : 8;
-    precision_type prectype : 8;
-    conversion_type type : 8;
+    unsigned flags;
+    width_type widthtype;
+    precision_type prectype;
+    conversion_type type;
     interned_string literal_string;
     bool is_empty() const
     {

Hi,

I had a similar problem with gcc 4.5.2 and fixed it as follows.

--------------------------------- staptree.h ----------------------------------
index a376a43..d1e2da4 100644
@@ -519,9 +519,9 @@ struct print_format: public expression
     unsigned width;
     unsigned precision;
     unsigned flags : 8;
-    width_type widthtype : 8;
-    precision_type prectype : 8;
-    conversion_type type : 8;
+    unsigned char widthtype : 8;
+    unsigned char prectype : 8;
+    unsigned char type : 8;
     interned_string literal_string;
     bool is_empty() const
     {

Additionally, I build staprun for an ARM target with arm-unknown-linux-gnueabi-gcc (crosstool-NG 1.12.1 - buildroot 2011.08) 4.4.3. Here I need an additional patch.

Hack: std::string is missing.
    
Provide std::string as part of util.h as it missing in string.h.

------------------------------------ util.h ------------------------------------
index e642c5e..e4fdae4 100644
@@ -144,6 +144,15 @@ inline std::string lex_cast(IN const & in)
 
 #if __cplusplus < 201103L
 // Older C++0x only had the "long long" implementations, so we cast up.
+#  if (__GNUC__ == 4 && __GNUC_MINOR__ == 4)
+namespace std {
+    static std::string to_string(size_t n) {
+        std::ostringstream s;
+        s << n;
+        return s.str();
+    }
+}
+#  endif
 #define INT_TO_STRING(IN) \
   LEX_CAST_TO_STRING(signed IN, long long) \
   LEX_CAST_TO_STRING(unsigned IN, unsigned long long)


Kind Regards,
Torsten

(In reply to David Smith from comment #3)
> > ...
> > From 1.7 to 2.9 it compiles ok. The issue seems to be from 3.0 on
> > (basically, 3.0, 3.1 and 3.2).
> 
> According to the NEWS file:
> 
> ====
> * What's new in version 3.1, 2017-02-17
> 
> - Systemtap now needs C++11 to build.
> ====
> 
> The configure script tries to check for C++11 support, by seeing if your
> compiler supports the '-std=c++0x' option. In your config.log file, what is
> HAVE_CXX11 set to?

Thank you for your quick response.

Weird because the configure script ended up assuming that the C++ compiler supports the 2011 ISO C++ standard:

...
checking whether g++ supports C++11 features by default... no
checking whether g++ supports C++11 features with -std=c++11... no
checking whether g++ supports C++11 features with -std=c++0x... no
checking whether g++ supports C++11 features with +std=c++11... no
checking whether g++ supports C++11 features with -h std=c++11... no
configure: No compiler with C++11 support was found
checking whether C++ compiler accepts -std=c++0x... yes
configure: Compiling with -std=c++0x
...

$ grep CXX11 systemtap*/config.log
systemtap-3.1/config.log:HAVE_CXX11='1'
systemtap-3.2/config.log:HAVE_CXX11='1'
systemtap/config.log:HAVE_CXX11='1'

* systemtap/config.log is the latest git master.
** NB: systemtap-3.0 doesn't check for CXX11, and it doesn't compile due to the same issue.

Actually, I've tested the following code and it works:

test.cpp:
 enum AnEnum { BLAH1 = 1, BLAH2 = 2 };

 struct St
 {
     AnEnum Field : 8;
 };  

 main() {
     St st;
 }


$ g++ -std=c++11 test.cpp; echo $?
0
$ g++ -std=c++0x test.cpp; echo $?
0


Anyway, C++11 features were being developed from GCC 4.3 to 4.8.1, so with that I'm just testing one of the features already supported in 4.7.

(In reply to Torsten.Polle from comment #5)
> Hi,
> 
> I had a similar problem with gcc 4.5.2 and fixed it as follows.
> 
> --------------------------------- staptree.h
> ----------------------------------
> index a376a43..d1e2da4 100644
> @@ -519,9 +519,9 @@ struct print_format: public expression
>      unsigned width;
>      unsigned precision;
>      unsigned flags : 8;
> -    width_type widthtype : 8;
> -    precision_type prectype : 8;
> -    conversion_type type : 8;
> +    unsigned char widthtype : 8;
> +    unsigned char prectype : 8;
> +    unsigned char type : 8;
>      interned_string literal_string;
>      bool is_empty() const
>      {
> 
> Additionally, I build staprun for an ARM target with
> arm-unknown-linux-gnueabi-gcc (crosstool-NG 1.12.1 - buildroot 2011.08)
> 4.4.3. Here I need an additional patch.
> 
> Hack: std::string is missing.
>     
> Provide std::string as part of util.h as it missing in string.h.
> 
> ------------------------------------ util.h
> ------------------------------------
> index e642c5e..e4fdae4 100644
> @@ -144,6 +144,15 @@ inline std::string lex_cast(IN const & in)
>  
>  #if __cplusplus < 201103L
>  // Older C++0x only had the "long long" implementations, so we cast up.
> +#  if (__GNUC__ == 4 && __GNUC_MINOR__ == 4)
> +namespace std {
> +    static std::string to_string(size_t n) {
> +        std::ostringstream s;
> +        s << n;
> +        return s.str();
> +    }
> +}
> +#  endif
>  #define INT_TO_STRING(IN) \
>    LEX_CAST_TO_STRING(signed IN, long long) \
>    LEX_CAST_TO_STRING(unsigned IN, unsigned long long)
> 
> 
> Kind Regards,
> Torsten

Thanks Torsten, awesome. 

I wonder why it's failing, because it's not due to the CXX11's "Strongly-typed enums" feature. Actually, I've tested it separately and this feature works with G++ 4.7 (have a look to my response to David@). It seems to be failing inside STL. 

PS: The 8bit bit-field is redundant for char type, but yeah it doesn't hurt ;)

Thanks again,
Gus

(In reply to Frank Ch. Eigler from comment #4)
> Just a guess - does this hypothetical patch fix your build?
> 
> diff --git a/staptree.h b/staptree.h
> index a376a436b88b..84d4fec63db9 100644
> --- a/staptree.h
> +++ b/staptree.h
> @@ -518,10 +518,10 @@ struct print_format: public expression
>      unsigned base;
>      unsigned width;
>      unsigned precision;
> -    unsigned flags : 8;
> -    width_type widthtype : 8;
> -    precision_type prectype : 8;
> -    conversion_type type : 8;
> +    unsigned flags;
> +    width_type widthtype;
> +    precision_type prectype;
> +    conversion_type type;
>      interned_string literal_string;
>      bool is_empty() const
>      {

Thanks Frank, yeah patching it that way also works. 

Same concern I asked to Torsten@ and David@ :
"I wonder why it's failing, because it's not due to the CXX11's "Strongly-typed enums" feature. Actually, I've tested it separately and this feature works with G++ 4.7 (have a look to my response to David@). It seems to be failing inside STL."

Cheers,
Gus

Understanding that this is probably a bug in an older toolchain, the only choice we have is whether we support it (with its mystery bugs/limitations) or not.  IMHO if we can easily support it, we should.

Going to close this issue as currently supported distributions are using newer versions of GCC that should support C++11 (GCC-4.8.1 https://gcc.gnu.org/projects/cxx-status.html#cxx11).