GNU bug report logs - #68832
Testing: POSIX yacc and C++ linkage

Previous Next

To reply to this bug, email your comments to 68832 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Marcel Telka <marcel <at> telka.sk>
To: bug-automake <at> gnu.org
Subject: Testing: POSIX yacc and C++ linkage
Date: Tue, 30 Jan 2024 21:35:41 +0100

[Message part 1 (text/plain, inline)]

Hi,

I ran tests for automake 1.16.5 on OpenIndiana and following 4 tests
failed:

FAIL: t/yacc-cxx.sh
FAIL: t/yacc-clean-cxx.sh
FAIL: t/yacc-d-cxx.sh
FAIL: t/yacc-mix-c-cxx.sh


The cause for the failure is this:

parse1.yy:30:7: error: conflicting declaration of 'void yyerror(const char*)' with 'C' linkage
parse1.yy:7:6: note: previous declaration with 'C++' linkage
    7 | void yyerror (const char *s) {}
      |      ^~~~~~~
parse1.yy:34:6: error: conflicting declaration of 'int yylex()' with 'C' linkage
parse1.yy:6:5: note: previous declaration with 'C++' linkage
    6 | int yylex (void) { return std::getchar (); }
      |     ^~~~~


For testing there is the default system yacc used.  It is the illumos
yacc as inherited from Solaris with some changes[1].  The generated code
that causes the failure is this:

 24 #if defined(__cplusplus) || defined(__STDC__)
 25 
 26 #if defined(__cplusplus)
 27 extern "C" {
 28 #endif
 29 #ifndef yyerror
 30 #if defined(__cplusplus)
 31         void yyerror(YYCONST char *);
 32 #endif
 33 #endif
 34 #ifndef yylex
 35         int yylex(void);
 36 #endif
 37         int yyparse(void);
 38 #if defined(__cplusplus)
 39 }
 40 #endif
 41 
 42 #endif

The issue is apparent.  The yacc generated code create both yyerror()
and yylex() with the C linkage, but testing expects C++ linkage.  This
is exactly what the compiler error says.

All of this is obvious.  So where is the bug and what should be fixed?
There are few possible views:

1. yacc is buggy and should not force C linkage for C++ source.  This is
grey area because POSIX says nothing about linkage or C++[2].

2. The tests' expectations about yacc behavior re C++ are too strong.
This seems to be true for illumos yacc.  Other yacc implementations, for
example GNU bison, does better job and do not force C linkage for
affected functions.

My proposal to solve the issue is to change affected tests to require
bison instead of yacc.  Please see attachment.


Thank you.


[1] for example this: https://www.illumos.org/issues/16136
[2] https://pubs.opengroup.org/onlinepubs/9699919799/utilities/yacc.html

-- 
+-------------------------------------------+
| Marcel Telka   e-mail:   marcel <at> telka.sk  |
|                homepage: http://telka.sk/ |
+-------------------------------------------+

[automake-1.16.5-test-yacc-cxx-bison.patch (text/plain, attachment)]

Message #8 received at 68832 <at> debbugs.gnu.org (full text, mbox):

From: Karl Berry <karl <at> freefriends.org>
To: marcel <at> telka.sk
Cc: 68832 <at> debbugs.gnu.org
Subject: Re: bug#68832: Testing: POSIX yacc and C++ linkage
Date: Wed, 31 Jan 2024 15:47:09 -0700

    parse1.yy:30:7: error: conflicting declaration of 'void yyerror(const char*)' with 'C' linkage
    parse1.yy:7:6: note: previous declaration with 'C++' linkage

Thanks much for the careful and complete report.

I think this is another manifestation of what Bogdan fixed in other
cases in https://debbugs.gnu.org/cgi/bugreport.cgi?bug=62886. His idea
there was to essentially add an extern "C" only on Solaris, via
sufficient #ifdef's.

In these new cases, I guess braces would be required, so the test code
would end up looking like:

#if (defined __cplusplus) && ((!defined __sun) || (defined __EXTERN_C__))
extern "C" {
#endif
int yylex (void) { return std::getchar (); }
void yyerror (const char *s) {}
#if (defined __cplusplus) && ((!defined __sun) || (defined __EXTERN_C__))
}
#endif

Although I could try to do this, I can't easily test the result, and I'd
probably mess up the editing. I'm also far from sure that this will
actually solve the problem without introducing new ones.

So maybe you could edit one of the test *.sh files and rerun the test
and see what happens? In case you don't know, you can run a single test
with, e.g.,
  make check TESTS='t/yacc-cxx.sh' keep_testdirs=yes
(the keep_testdirs keeps the <testdir>.dir/ around so it can be
inspected afterward.)

    My proposal to solve the issue is to change affected tests to
    require bison instead of yacc.  

A lot of work has gone into making the tests work with Solaris tools
(despite the current failures), so I'm reluctant to throw that
possibility away.

Also, there have been similar bug reports with older versions of bison.
There is no panacea :( ...  --thanks, karl.

Message #11 received at 68832 <at> debbugs.gnu.org (full text, mbox):

From: Bogdan <bogdro_rep <at> gmx.us>
To: 68832 <at> debbugs.gnu.org
Subject: [bug#68832][PATCH] Testing: POSIX yacc and C++ linkage
Date: Tue, 6 Feb 2024 22:02:04 +0100

[Message part 1 (text/plain, inline)]

Hi.

 I have access to just Linux and SunOS and cannot reproduce the error
(the tests pass), but Karl's solution seems reasonable and shouldn't hurt.
 Attaching a simple patch which (hopefully) fixes the issue. At
least, it doesn't hurt Linux or SunOS, so it shouldn't make things
worse. Feel free to reformat if needed (indents, empty lines, etc.).


--
Regards - Bogdan ('bogdro') D.                 (GNU/Linux & FreeDOS)
X86 assembly (DOS, GNU/Linux):    http://bogdro.evai.pl/index-en.php
Soft(EN): http://bogdro.evai.pl/soft  http://bogdro.evai.pl/soft4asm
www.Xiph.org  www.TorProject.org  www.LibreOffice.org  www.GnuPG.org

[automake-openindiana-fix-mail.diff (text/x-patch, attachment)]

Message #14 received at 68832 <at> debbugs.gnu.org (full text, mbox):

From: Karl Berry <karl <at> freefriends.org>
To: marcel <at> telka.sk
Cc: 68832 <at> debbugs.gnu.org
Subject: Re: bug#68832: [PATCH] Testing: POSIX yacc and C++ linkage
Date: Wed, 7 Feb 2024 16:01:03 -0700

      Attaching a simple patch 

Thanks Bogdan! I pushed those changes.

Marcel, if you're able to try testing from the repo, that would be
great.  Else it hopefully won't be too long before the next pretest
(or, even more optimistically, the next release). -karl

Message #17 received at 68832 <at> debbugs.gnu.org (full text, mbox):

From: Marcel Telka <marcel <at> telka.sk>
To: 68832 <at> debbugs.gnu.org
Subject: Test of automake-openindiana-fix-mail.diff
Date: Sat, 10 Feb 2024 01:56:20 +0100

Hi,

I tested automake-1.16 with the automake-openindiana-fix-mail.diff (minor
tweaks were needed because the patch refused to apply) and all four tests
failed as before.  That's not surprising because the patch is effectively no-op
on illumos because __sun is defined and __EXTERN_C__ is not defined.

Then I tried to change all guards from:

	#if (defined __cplusplus) && ((!defined __sun) || (defined __EXTERN_C__))

to

	#if (defined __cplusplus)


And all four tests still failed, but the failure was different:

/usr/gcc/13/bin/g++  -m64 -O3    -o foo1 parse1.o foo.o
Undefined                       first referenced
 symbol                             in file
_Z7yyparsev                         foo.o
ld: fatal: symbol referencing errors. No output written to foo1
collect2: error: ld returned 1 exit status


Thank you.

-- 
+-------------------------------------------+
| Marcel Telka   e-mail:   marcel <at> telka.sk  |
|                homepage: http://telka.sk/ |
+-------------------------------------------+

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.