Strange C++ error with GCC 9.0.1

[Peter Lemenkov]

Hello All!
I cannot build SIPp anymore. It fails with a very cryptic (for me) message:

https://koji.fedoraproject.org/koji/taskinfo?taskID=33763853

```
g++ -DHAVE_CONFIG_H -DUSE_OPENSSL -DPCAPPLAY -DRTP_STREAM -DUSE_SCTP
-DHAVE_EPOLL -I. -I./include   -D__LINUX -I./include -Wall -pedantic
-O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2
-Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong
-grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic
-fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection
-c -o src/sipp-sipp.o `test -f 'src/sipp.cpp' || echo
'./'`src/sipp.cpp
In file included from ./include/strings.hpp:24,
                 from ./include/sipp.hpp:484,
                 from src/sipp.cpp:41:
/usr/include/c++/9/cstddef:52:8: error: expected unqualified-id before
string constant
   52 | extern "C++"
      |        ^~~~~
make[1]: *** [Makefile:1768: src/sipp-sipp.o] Error 1
make[1]: *** Waiting for unfinished jobs....
make[1]: Leaving directory '/home/petro/rpmbuild/BUILD/sipp-3.5.2'
make: *** [Makefile:830: all] Error 2
error: Bad exit status from /var/tmp/rpm-tmp.Y5CFt4 (%build)
```
^^^ That's exactly where I'm stuck now. This is how my
`/usr/include/c++/9/cstddef` looks like:

*
https://github.com/gcc-mirror/gcc/blob/25694c85/libstdc%2B%2B-v3/include/...

And I tend to think that this issue is related to this commit:

* https://github.com/gcc-mirror/gcc/commit/038feca5beacbe36e28680c8e1a8af83...

-- 
With best regards, Peter Lemenkov.

[Jakub Jelinek]

On Wed, Mar 27, 2019 at 03:48:41PM +0100, Peter Lemenkov wrote:
>  I cannot build SIPp anymore. It fails with a very cryptic (for me)
> message:
>  
>  https://koji.fedoraproject.org/koji/taskinfo?taskID=33763853
>  
>  ```
>  g++ -DHAVE_CONFIG_H -DUSE_OPENSSL -DPCAPPLAY -DRTP_STREAM -DUSE_SCTP
>  -DHAVE_EPOLL -I. -I./include   -D__LINUX -I./include -Wall -pedantic
>  -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2
>  -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong
>  -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
>  -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic
>  -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection
>  -c -o src/sipp-sipp.o `test -f 'src/sipp.cpp' || echo
>  './'`src/sipp.cpp
>  In file included from ./include/strings.hpp:24,
>                   from ./include/sipp.hpp:484,
>                   from src/sipp.cpp:41:
>  /usr/include/c++/9/cstddef:52:8: error: expected unqualified-id before
>  string constant
>     52 | extern "C++"
>        |        ^~~~~
>  make[1]: *** [Makefile:1768: src/sipp-sipp.o] Error 1
>  make[1]: *** Waiting for unfinished jobs....
>  make[1]: Leaving directory '/home/petro/rpmbuild/BUILD/sipp-3.5.2'
>  make: *** [Makefile:830: all] Error 2
>  error: Bad exit status from /var/tmp/rpm-tmp.Y5CFt4 (%build)
>  ```
>  ^^^ That's exactly where I'm stuck now. This is how my
>  `/usr/include/c++/9/cstddef` looks like:
>  
>  *
> https://github.com/gcc-mirror/gcc/blob/25694c85/libstdc%2B%2B-v3/include/...
>  
>  And I tend to think that this issue is related to this commit:
>  
>  * https://github.com/gcc-mirror/gcc/commit/038feca5beacbe36e28680c8e1a8af83...
You should look at what comes before that token and from where,
that might be a reason why the extern "C++" is rejected at that spot.
So, preprocess it (-save-temps or -E -o src/sipp-sipp.ii) and look in the
preprocessed dump.  Perhaps cstddef is included in some context where it
shouldn't be or there are macros redefining extern or similar bogosities.

	Jakub

[Peter Lemenkov]

Jakub, thanks for the tip! Now I moved a little further. I've added
-save-temps to CXXFLAGS and indeed there is something wrong. Here is
how this cstddef file was included:

===========
# 1 "/usr/lib/gcc/x86_64-redhat-linux/9/include/stddef.h" 1 3 4
# 51 "/usr/include/c++/9/cstddef" 2 3


# 52 "/usr/include/c++/9/cstddef" 3
      "C++"
{

namespace std
{

  using ::max_align_t;
}
# 197 "/usr/include/c++/9/cstddef" 3
}
# 25 "./include/strings.hpp" 2

===========

Note the missing extern pragma before "C++" token.

ср, 27 мар. 2019 г. в 15:58, Jakub Jelinek <jakub(a)redhat.com&gt;:
>  On Wed, Mar 27, 2019 at 03:48:41PM +0100, Peter Lemenkov wrote:
>  > I cannot build SIPp anymore. It fails with a very cryptic (for me) message:
>  >
>  > https://koji.fedoraproject.org/koji/taskinfo?taskID=33763853
>  >
>  > ```
>  > g++ -DHAVE_CONFIG_H -DUSE_OPENSSL -DPCAPPLAY -DRTP_STREAM -DUSE_SCTP
>  > -DHAVE_EPOLL -I. -I./include   -D__LINUX -I./include -Wall -pedantic
>  > -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2
>  > -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong
>  > -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
>  > -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic
>  > -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection
>  > -c -o src/sipp-sipp.o `test -f 'src/sipp.cpp' || echo
>  > './'`src/sipp.cpp
>  > In file included from ./include/strings.hpp:24,
>  >                  from ./include/sipp.hpp:484,
>  >                  from src/sipp.cpp:41:
>  > /usr/include/c++/9/cstddef:52:8: error: expected unqualified-id before
>  > string constant
>  >    52 | extern "C++"
>  >       |        ^~~~~
>  > make[1]: *** [Makefile:1768: src/sipp-sipp.o] Error 1
>  > make[1]: *** Waiting for unfinished jobs....
>  > make[1]: Leaving directory '/home/petro/rpmbuild/BUILD/sipp-3.5.2'
>  > make: *** [Makefile:830: all] Error 2
>  > error: Bad exit status from /var/tmp/rpm-tmp.Y5CFt4 (%build)
>  > ```
>  > ^^^ That's exactly where I'm stuck now. This is how my
>  > `/usr/include/c++/9/cstddef` looks like:
>  >
>  > *
> https://github.com/gcc-mirror/gcc/blob/25694c85/libstdc%2B%2B-v3/include/...
>  >
>  > And I tend to think that this issue is related to this commit:
>  >
>  > * https://github.com/gcc-mirror/gcc/commit/038feca5beacbe36e28680c8e1a8af83...
>
>  You should look at what comes before that token and from where,
>  that might be a reason why the extern "C++" is rejected at that spot.
>  So, preprocess it (-save-temps or -E -o src/sipp-sipp.ii) and look in the
>  preprocessed dump.  Perhaps cstddef is included in some context where it
>  shouldn't be or there are macros redefining extern or similar bogosities.
>
>          Jakub
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>  Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
>  List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>  List Archives:
> https://lists.fedoraproject.org/archives/list/[e-mail] 


-- 
With best regards, Peter Lemenkov.

[Jakub Jelinek]

On Wed, Mar 27, 2019 at 04:08:59PM +0100, Peter Lemenkov wrote:
>  Jakub, thanks for the tip! Now I moved a little further. I've
> added
>  -save-temps to CXXFLAGS and indeed there is something wrong. Here is
>  how this cstddef file was included:
>  
>  ===========
>  # 1 "/usr/lib/gcc/x86_64-redhat-linux/9/include/stddef.h" 1 3 4
>  # 51 "/usr/include/c++/9/cstddef" 2 3
>  
>  
>  # 52 "/usr/include/c++/9/cstddef" 3
>        "C++"
>  {
>  
>  namespace std
>  {
>  
>    using ::max_align_t;
>  }
>  # 197 "/usr/include/c++/9/cstddef" 3
>  }
>  # 25 "./include/strings.hpp" 2 
You can use -E -dD to see what macros are defined and where.
If the app does
#define extern
before including system headers, then it obviously needs to be fixed.
It can do that before its own include headers if it makes sure it will work,
but system headers of course should be able to use extern whenever it makes
sense in there.

	Jakub

[Jonathan Wakely]

On 27/03/19 16:13 +0100, Jakub Jelinek wrote:
> On Wed, Mar 27, 2019 at 04:08:59PM +0100, Peter Lemenkov wrote:
> > Jakub, thanks for the tip! Now I moved a little further. I've added
> > -save-temps to CXXFLAGS and indeed there is something wrong. Here is
> > how this cstddef file was included:
> >
> > ===========
> > # 1 "/usr/lib/gcc/x86_64-redhat-linux/9/include/stddef.h" 1 3 4
> > # 51 "/usr/include/c++/9/cstddef" 2 3
> >
> >
> > # 52 "/usr/include/c++/9/cstddef" 3
> >       "C++" 
Wow, somebody did something very silly.

> > {
> >
> > namespace std
> > {
> >
> >   using ::max_align_t;
> > }
> > # 197 "/usr/include/c++/9/cstddef" 3
> > }
> > # 25 "./include/strings.hpp" 2
>
> You can use -E -dD to see what macros are defined and where.
> If the app does
> #define extern
> before including system headers, then it obviously needs to be fixed.
> It can do that before its own include headers if it makes sure it will work, 
It's undefined behaviour to do so, but I guess if they want to deal
with that, that's their problem.

"A translation unit shall not #define or #undef names lexically
identical to keywords, "

>but system headers of course should be able to use extern whenever it makes
>sense in there.
>
>	Jakub

[Jonathan Wakely]

On 27/03/19 16:37 +0000, Jonathan Wakely wrote:
> On 27/03/19 16:13 +0100, Jakub Jelinek wrote:
> >On Wed, Mar 27, 2019 at 04:08:59PM +0100, Peter Lemenkov wrote:
> >>Jakub, thanks for the tip! Now I moved a little further. I've added
> >>-save-temps to CXXFLAGS and indeed there is something wrong. Here is
> >>how this cstddef file was included:
> >>
> >>===========
> >># 1 "/usr/lib/gcc/x86_64-redhat-linux/9/include/stddef.h" 1 3 4
> >># 51 "/usr/include/c++/9/cstddef" 2 3
> >>
> >>
> >># 52 "/usr/include/c++/9/cstddef" 3
> >>      "C++"
>
> Wow, somebody did something very silly. 
And here it is:
https://github.com/SIPp/sipp/blob/fc348b8539949b0533a259e81923ed64e22f465...

A less ridiculous way to do that would be:

#ifdef GLOBALS_FULL_DEFINITION
#define MAYBE_EXTERN
#define _DEFVAL(value) = value
#else
#define MAYBE_EXTERN extern
#define _DEFVAL(value)
#endif

and then use MAYBE_EXTERN instead of extern.

The _DEFVAL is also undefined behaviour, because that's a reserved
name. It should be DEFVAL.

[Peter Lemenkov]

Jonathan, thanks for the tip! It works now!

How cool is that we have a lot of experts in almost every aspect of
software development around?


ср, 27 мар. 2019 г. в 17:43, Jonathan Wakely <jwakely(a)fedoraproject.org&gt;:
>  On 27/03/19 16:37 +0000, Jonathan Wakely wrote:
>  >On 27/03/19 16:13 +0100, Jakub Jelinek wrote:
>  >>On Wed, Mar 27, 2019 at 04:08:59PM +0100, Peter Lemenkov wrote:
>  >>>Jakub, thanks for the tip! Now I moved a little further. I've added
>  >>>-save-temps to CXXFLAGS and indeed there is something wrong. Here is
>  >>>how this cstddef file was included:
>  >>>
>  >>>===========
>  >>># 1 "/usr/lib/gcc/x86_64-redhat-linux/9/include/stddef.h" 1 3 4
>  >>># 51 "/usr/include/c++/9/cstddef" 2 3
>  >>>
>  >>>
>  >>># 52 "/usr/include/c++/9/cstddef" 3
>  >>>      "C++"
>  >
>  >Wow, somebody did something very silly.
>
>  And here it is:
>
> https://github.com/SIPp/sipp/blob/fc348b8539949b0533a259e81923ed64e22f465...
>
>  A less ridiculous way to do that would be:
>
>  #ifdef GLOBALS_FULL_DEFINITION
>  #define MAYBE_EXTERN
>  #define _DEFVAL(value) = value
>  #else
>  #define MAYBE_EXTERN extern
>  #define _DEFVAL(value)
>  #endif
>
>  and then use MAYBE_EXTERN instead of extern.
>
>  The _DEFVAL is also undefined behaviour, because that's a reserved
>  name. It should be DEFVAL.
>
>  

-- 
With best regards, Peter Lemenkov.

[J. Scheurich]

>  g++ -DHAVE_CONFIG_H -DUSE_OPENSSL -DPCAPPLAY -DRTP_STREAM -DUSE_SCTP
>  -DHAVE_EPOLL -I. -I./include   -D__LINUX -I./include -Wall -pedantic
>  -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2
>  -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong
>  -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
>  -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic
>  -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection
>  -c -o src/sipp-sipp.o `test -f 'src/sipp.cpp' || echo
>  './'`src/sipp.cpp
>  In file included from ./include/strings.hpp:24,
>                    from ./include/sipp.hpp:484,
>                    from src/sipp.cpp:41:
>  /usr/include/c++/9/cstddef:52:8: error: expected unqualified-id before
>  string constant
>      52 | extern "C++"
>         |        ^~~~~
>  make[1]: *** [Makefile:1768: src/sipp-sipp.o] Error 1 
https://en.cppreference.com/w/cpp/language/language_linkage
...
| Only two language linkages are guaranteed to be supported:
| 1) "C++", the default language linkage.
| 2) "C", which makes it possible to link with functions written in the
| C programming language, and to define, in a C++ program, functions
| that can be called from the modules written in C.

Cause  'extern "C++"' is the default for C++ and the compiler is g++,
you should be able to simply delete 'extern "C++"', is should have no
effect.

so long
MUFTI

[Jonathan Wakely]

On 27/03/19 16:54 +0100, J. Scheurich wrote:
> >g++ -DHAVE_CONFIG_H -DUSE_OPENSSL -DPCAPPLAY -DRTP_STREAM -DUSE_SCTP
> >-DHAVE_EPOLL -I. -I./include   -D__LINUX -I./include -Wall -pedantic
> >-O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2
> >-Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong
> >-grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
> >-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic
> >-fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection
> >-c -o src/sipp-sipp.o `test -f 'src/sipp.cpp' || echo
> >'./'`src/sipp.cpp
> >In file included from ./include/strings.hpp:24,
> >                  from ./include/sipp.hpp:484,
> >                  from src/sipp.cpp:41:
> >/usr/include/c++/9/cstddef:52:8: error: expected unqualified-id before
> >string constant
> >    52 | extern "C++"
> >       |        ^~~~~
> >make[1]: *** [Makefile:1768: src/sipp-sipp.o] Error 1
>
> https://en.cppreference.com/w/cpp/language/language_linkage
> ...
> | Only two language linkages are guaranteed to be supported:
> | 1) "C++", the default language linkage.
> | 2) "C", which makes it possible to link with functions written in the
> | C programming language, and to define, in a C++ program, functions
> | that can be called from the modules written in C.
>
> Cause  'extern "C++"' is the default for C++ and the compiler is g++,
> you should be able to simply delete 'extern "C++"', is should have no
> effect. 
That's not true at all:

extern "C" {
extern "C++" void f();
}

extern "C++" {
void g();
}

If you remove the first occurrence of extern "C++" then you change the
language linkage of f() and if you remove the second occurrence then
you have just { at namespace scope, which is ill-formed.