GNU bug report logs - #62886
[PATCH][bug 34151, 42393, 44795, 49755, 45205, 55073] Fix lex/yacc C++ tests on Solaris/SunOS

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 62886 in the body.
You can then email your comments to 62886 AT debbugs.gnu.org in the normal way.

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

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

From: Bogdan <bogdro_rep <at> gmx.us>
To: automake-patches <at> gnu.org, 34151 <at> debbugs.gnu.org, 42393 <at> debbugs.gnu.org,
 44795 <at> debbugs.gnu.org, 49755 <at> debbugs.gnu.org, 45205 <at> debbugs.gnu.org,
 55073 <at> debbugs.gnu.org
Subject: [PATCH][bug 34151, 42393, 44795, 49755, 45205, 55073] Fix lex/yacc
 C++ tests on Solaris/SunOS
Date: Sun, 16 Apr 2023 18:37:28 +0200

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

Hi all.

 The Solaris/SunOS lex generates C++ code with functions properly 
wrapped into >extern "C"<, but only if:

- compiling as C++ (__cplusplus is #defined),

- the feature constant __EXTERN_C__ is #defined (probably meant just 
for the SunOS compiler, not for all).

Other compilers, like GCC/G++, obviously miss the SunOS-specific 
__EXTERN_C__ and thus miss >extern "C"<, declaring the yylex() 
function as C++ (the default). This doesn't need to be a problem, but:

- the function should be declared as the user code expects it (as C 
for C programs and as C++ for C++ programs),

- the Automake lex tests for C++ re-declare the function always as a C 
function.

 The re-declarations happens probably for good reason, like for lex 
implementations which don't declare the function in advance combined 
with C/C++ compilers which always require declarations. Unfortunately, 
having the same function declared as C++ (default) first and then 
later as C causes compiler errors.

 The attached patch corrects the declarations in the following way:

- if we're in C++ mode and __EXTERN_C__ is declared (so, we're on a 
SunOS with their compiler), declare the function as C in C++ mode 
(i.e., use >extern "C"<), just like the SunOS lex does,

- if we're in C++ mode and __EXTERN_C__ is NOT declared, but also 
"__sun" is not declared (so, we're NOT on a SunOS), still assume C++ 
mode, but a different system and declare the function as C in C++ mode 
(i.e., use >extern "C"<) to support other compilers,

- if we're in C++ mode and __EXTERN_C__ is NOT declared, but also 
"__sun" IS declared (so, we ARE on a SunOS, but not using their 
compiler), declare the function as C++ in C++ mode, just like the 
SunOS lex does,

- if we're NOT in C++ mode, declare the function as C. Not the case in 
these tests, though.

 This should match what the SunOS lex/compiler do and expect which 
not braking other systems (re-checked on my Linux - works).

 Verified that the defect exists on a Solaris 11.4 Build 15 (SunOS 
5.11, GCC 7.3.0, amd64) and that the patch fixes it.

 Furthermore, I checked how GCC manages the declarations of standard 
C functions in C++. Seems so simple as saying:

	using std::some_c_library_function_name;

 which the SunOS library (or maybe just the old GCC library there) is 
not doing.
 So, it just takes this to fix the missing prototypes in C++ mode.

 In short, the patch:
- fixes the remaining part of 
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=34151,
- fixes the remaining part of 
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=42393 
(t/silent-many-languages.sh works for me),
- fixes https://debbugs.gnu.org/cgi/bugreport.cgi?bug=44795,
- fixes https://debbugs.gnu.org/cgi/bugreport.cgi?bug=49755,
- partially fixes https://debbugs.gnu.org/cgi/bugreport.cgi?bug=45205,
- partially fixes https://debbugs.gnu.org/cgi/bugreport.cgi?bug=55073.

 Fortunately, these parts are just problems with the tests 
themselves, not with Automake in general.

-- 
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-sunos2-mail.diff (text/x-patch, attachment)]

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

From: Bogdan <bogdro_rep <at> gmx.us>
To: 62886 <at> debbugs.gnu.org
Subject: Unnecessary bug registered
Date: Sun, 16 Apr 2023 18:43:58 +0200

The bugtracker erroneously thought my previous mail was a new bug 
report...

To be closed/deleted, just like 
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=60419.

-- 
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

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

From: Karl Berry <karl <at> freefriends.org>
To: bogdro_rep <at> gmx.us
Cc: 62886 <at> debbugs.gnu.org, 62886-done <at> debbugs.gnu.org
Subject: Re: [bug#62886] Unnecessary bug registered
Date: Sat, 27 May 2023 19:22:04 -0600

Closing bug as suggested. Mailing or cc-ing NNNN-done <at> debbugs.gnu.org
will close a bug.

    To be closed/deleted, just like 
    https://debbugs.gnu.org/cgi/bugreport.cgi?bug=60419.

Merging that one. --thanks, karl.

Previous Next

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