From @jkeenan

Go to http​://perl5.test-smoke.org/search and select 'netbsd', '8.0' and
'g++' from the top 3 drop-downs on the right-hand side.

It appears this has been the case ever we since we started to get smoke
test reports from Carlos in September 2018.

blead does appear to build on NetBSD-7.2 with g++ (modulo test failures
reported in other tickets).

blead does appear to build on NetBSD-8.0 with gcc (same qualification).

Thank you very much.
Jim Keenan

perl perl perl

From @khwilliamson

On 4/11/19 12​:45 PM, James E Keenan (via RT) wrote​:

# New Ticket Created by James E Keenan
# Please include the string​: [perl #134023]
# in the subject line of all future correspondence about this issue.
# <URL​: https://rt-archive.perl.org/perl5/Ticket/Display.html?id=134023 >

Go to http​://perl5.test-smoke.org/search and select 'netbsd', '8.0' and
'g++' from the top 3 drop-downs on the right-hand side.

It appears this has been the case ever we since we started to get smoke
test reports from Carlos in September 2018.

blead does appear to build on NetBSD-7.2 with g++ (modulo test failures
reported in other tickets).

blead does appear to build on NetBSD-8.0 with gcc (same qualification).

Thank you very much.
Jim Keenan

perl perl perl

I had noticed that a while back, and just not investigated. There's
something wrong/different with static asserts in this version of g++

The RT System itself - Status changed from 'new' to 'open'

From @jkeenan

On Thu, 11 Apr 2019 19​:58​:50 GMT, public@​khwilliamson.com wrote​:

On 4/11/19 12​:45 PM, James E Keenan (via RT) wrote​:

# New Ticket Created by James E Keenan
# Please include the string​: [perl #134023]
# in the subject line of all future correspondence about this issue.
# <URL​: https://rt-archive.perl.org/perl5/Ticket/Display.html?id=134023 >

Go to http​://perl5.test-smoke.org/search and select 'netbsd', '8.0' and
'g++' from the top 3 drop-downs on the right-hand side.

It appears this has been the case ever we since we started to get smoke
test reports from Carlos in September 2018.

blead does appear to build on NetBSD-7.2 with g++ (modulo test failures
reported in other tickets).

blead does appear to build on NetBSD-8.0 with gcc (same qualification).

Thank you very much.
Jim Keenan

perl perl perl

I had noticed that a while back, and just not investigated. There's
something wrong/different with static asserts in this version of g++.

Can you elaborate on what you think the problems with this version of g++ are?

Should we expect them to show up other OS/version combinations?

Thank you very much.

--
James E Keenan (jkeenan@​cpan.org)

From @khwilliamson

On 4/29/19 4​:32 PM, James E Keenan via RT wrote​:

On Thu, 11 Apr 2019 19​:58​:50 GMT, public@​khwilliamson.com wrote​:

On 4/11/19 12​:45 PM, James E Keenan (via RT) wrote​:

# New Ticket Created by James E Keenan
# Please include the string​: [perl #134023]
# in the subject line of all future correspondence about this issue.
# <URL​: https://rt-archive.perl.org/perl5/Ticket/Display.html?id=134023 >

Go to http​://perl5.test-smoke.org/search and select 'netbsd', '8.0' and
'g++' from the top 3 drop-downs on the right-hand side.

It appears this has been the case ever we since we started to get smoke
test reports from Carlos in September 2018.

blead does appear to build on NetBSD-7.2 with g++ (modulo test failures
reported in other tickets).

blead does appear to build on NetBSD-8.0 with gcc (same qualification).

Thank you very much.
Jim Keenan

perl perl perl

I had noticed that a while back, and just not investigated. There's
something wrong/different with static asserts in this version of g++.

Can you elaborate on what you think the problems with this version of g++ are?

Should we expect them to show up other OS/version combinations?

Thank you very much.

All I know is that's where the logs indicate the failure is​:
p.c​: In function 'void S_maybe_multiconcat(OP*)'​:
perl.h​:3472​:61​: error​: '_Static_assert' was not declared in this scope
perl.h​:3488​:52​: note​: in expansion of macro 'STATIC_ASSERT_DECL'
op.c​:2861​:5​: note​: in expansion of macro 'STATIC_ASSERT_STMT'
op.c​:2863​:5​: note​: in expansion of macro 'STATIC_ASSERT_STMT'
op.c​: In function 'void Perl_rpeep(OP*)'​:
op.c​:15799​:21​: note​: in expansion of macro 'STATIC_ASSERT_STMT'
op.c​: In function 'void S_maybe_multiconcat(PerlInterpreter*, OP*)'​:
op.c​: In function 'OP* Perl_ck_rvconst(PerlInterpreter*, OP*)'​:
op.c​:11646​:6​: note​: in expansion of macro 'STATIC_ASSERT_STMT'
op.c​: In function 'void Perl_rpeep(PerlInterpreter*, OP*)'​:

From @iabyn

On Mon, Apr 29, 2019 at 04​:57​:09PM -0600, Karl Williamson wrote​:

On 4/29/19 4​:32 PM, James E Keenan via RT wrote​:

Should we expect them to show up other OS/version combinations?

No, this looks like a specific netbsd + g++ issue.

perl.h​:3472​:61​: error​: '_Static_assert' was not declared in this scope
perl.h​:3488​:52​: note​: in expansion of macro 'STATIC_ASSERT_DECL'

Perl.h has this​:

  #if (defined(static_assert) || (defined(__cplusplus) && __cplusplus >= 201103L)) && (!defined(__IBMC__) || __IBMC__ >= 1210)
  /* static_assert is a macro defined in <assert.h> in C11 or a compiler
  builtin in C++11. But IBM XL C V11 does not support _Static_assert, no
  matter what <assert.h> says.
  */
  # define STATIC_ASSERT_DECL(COND) static_assert(COND, #COND)
  #else
  ....

On my linux platform, /usr/include/assert.h has​:

  #if defined __USE_ISOC11 && !defined __cplusplus
  # undef static_assert
  # define static_assert _Static_assert
  #endif

and /usr/include/sys/cdefs.h has​:

  #if (!defined _Static_assert && !defined __cplusplus \
  && (defined __STDC_VERSION__ ? __STDC_VERSION__ : 0) < 201112 \
  && (!__GNUC_PREREQ (4, 6) || defined __STRICT_ANSI__))
  # define _Static_assert(expr, diagnostic) \
  extern int (*__Static_assert_function (void)) \
  [!!sizeof (struct { int __error_if_negative​: (expr) ? 2 : -1; })]
  #endif

I assume NetBSD 8++ has similar-ish header file(s), but something is not
quite right with all the version checks and/or the version of g++.

--
"I do not resent criticism, even when, for the sake of emphasis,
it parts for the time with reality".
  -- Winston Churchill, House of Commons, 22nd Jan 1941.

From coypu@sdf.org

yeah, the netbsd headers are wrong for this scenario.
_Static_assert is a thing for >= C11
static_assert is a thing for >= C++11.

The use of -ansi forces us to a really old standard so these are not available.

NetBSD should probably supply a fallback definition for _Static_assert like glibc does, or at least restrict the definition for when it is available.

I'd like to fix this in NetBSD (and backport it etc.)
Is a fix for Perl also desired?

From coypu@sdf.org

On Wed, 22 May 2019 05​:03​:18 -0700, coypu@​sdf.org wrote​:

Is a fix for Perl also desired?

And by fix I mean, "hack workaround", hence the question :-)

From @jkeenan

On Wed, 22 May 2019 12​:04​:13 GMT, coypu@​sdf.org wrote​:

On Wed, 22 May 2019 05​:03​:18 -0700, coypu@​sdf.org wrote​:

Is a fix for Perl also desired?

And by fix I mean, "hack workaround", hence the question :-)

Yes, a fix is desired. It appears evident to me (note​: note a NetBSD user) that the best place to address this problem would be in appropriate .c and .h header files such as those that have already been cited by Karl Williamson in this ticket.

For many uses, however, we can get by with changes to the hints/netbsd.sh file included in the Perl 5 core distribution. If you are not already familiar with that file, which is run as part of the configuration process, please take a look at it.

Thank you very much.
--
James E Keenan (jkeenan@​cpan.org)

From @khwilliamson

On Wed, 22 May 2019 05​:48​:07 -0700, jkeenan wrote​:

On Wed, 22 May 2019 12​:04​:13 GMT, coypu@​sdf.org wrote​:

On Wed, 22 May 2019 05​:03​:18 -0700, coypu@​sdf.org wrote​:

Is a fix for Perl also desired?

And by fix I mean, "hack workaround", hence the question :-)

Yes, a fix is desired. It appears evident to me (note​: note a NetBSD
user) that the best place to address this problem would be in
appropriate .c and .h header files such as those that have already
been cited by Karl Williamson in this ticket.

For many uses, however, we can get by with changes to the
hints/netbsd.sh file included in the Perl 5 core distribution. If you
are not already familiar with that file, which is run as part of the
configuration process, please take a look at it.

Thank you very much.

My reply did not make it to this ticket. And I now see that there was already something to the effect of what I was going to say, which is perl already has code to emulate static asserts for systems that don't have it.

https://rt-archive.perl.org/perl5/Ticket/Display.html?id=134023#txn-1629956

I'm thinking the definition there could be tweaked so that perl's definition is enabled in this situation. I don't really understand what copypu is proposing, but this option should be considered
--
Karl Williamson

From coypu@sdf.org

this is the netbsd fix, and will be in netbsd 8.1 when it is released (soon)​: http​://mail-index.netbsd.org/source-changes-hg/2019/05/29/msg057353.html

why the code was failing on netbsd​:

/* from netbsd assert.h */
#define static_assert bad_definition

/* from perl.h */
#ifndef static_assert
#define static_assert good_definition
#endif

why the definition was bad​:
it relied on GCC _Static_assert.
Building for old C++ standards it's not available.

From coypu@sdf.org

this is the netbsd fix, and will be in netbsd 8.1 when it is released (soon)​: http​://mail-index.netbsd.org/source-changes-hg/2019/05/29/msg057353.html

why the code was failing on netbsd​:

/* from netbsd assert.h */
#define static_assert bad_definition

/* from perl.h */
#ifndef static_assert
#define static_assert good_definition
#endif

why the definition was bad​:
it relied on GCC _Static_assert.
Building for old C++ standards it's not available.

I'm going to assume that the correction to include/assert.h did make it into NetBSD-8.1 (and that it will also be in the upcoming 9.0). I doubt the fix will be backported to 8.0. I don't think it's worth our while to alter our hints/netbsd.sh file for this. So I'm closing this ticket.

Thank you very much.
Jim Keenan