Bug#960608: Bison 3.6.1 generates (internal) tokentype and (yyerror) function with same name: _error
Hi!
> Le 14 mai 2020 à 18:47, Chuan-kai Lin a écrit :
>
> Hi Akim,
>
> I am forwarding a bug report that the libexplain and the fhist Debian
> packages fail to build with Bison 3.6.1.
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=960608
> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/libexplain.html
>
> I have also attached the build log with this email. Can you look into
> this issue and see if it is a bug in Bison? Thanks!
In the log file you sent, I see:
> libtool: compile: gcc -Wdate-time -D_FORTIFY_SOURCE=2 -g -O2
> -ffile-prefix-map=/build/1st/libexplain-1.4.D001=. -fstack-protector-strong
> -Wformat -Werror=format-security -Wall -Wextra -Wl,--as-needed -I. -c
> libexplain/acl_get_file_or_die.c -o libexplain/acl_get_file_or_die.o
> >/dev/null 2>&1
> bison -y -d libexplain/acl_grammar.y
> libexplain/acl_grammar.y:62.16-18: warning: POSIX yacc reserves %type to
> nonterminals [-Wyacc]
>62 | %type TAG
> |^~~
> libexplain/acl_grammar.y:63.19-24: warning: POSIX yacc reserves %type to
> nonterminals [-Wyacc]
>63 | %type NUMBER
> | ^~
> libexplain/acl_grammar.y:66.18-22: warning: POSIX yacc reserves %type to
> nonterminals [-Wyacc]
>66 | %type PERMS
> | ^
> libexplain/acl_grammar.y:68.17-20: warning: POSIX yacc reserves %type to
> nonterminals [-Wyacc]
>68 | %type NAME
> | ^~~~
> sed -e 's/[yY][yY]/acl_grammar_/g' -e '//d' -e \
> '//d' -e '//d' y.tab.c > \
> libexplain/acl_grammar.yacc.c
> sed -e 's/[yY][yY]/acl_grammar_/g' -e \
> 's/Y_TAB_H/libexplain_acl_grammar_YACC_H/g' y.tab.h > \
> libexplain/acl_grammar.yacc.h
The last two lines are not coming from Bison, and they are smashing
both YYerror and yyerror to acl_grammar_error. So of course, it fails.
I don't understand why this is done this way. The grammar file should use
%define api.prefix {acl_grammar_}, or the build system should pass
-Dapi.prefix={acl_grammar_}, or the sed sequence should be less crude.
I would go for
s/yy/acl_grammar_/g; s/YY/ACL_GRAMMAR_/g;
But if this is not ok, and the package still wants to smash yy and YY
to the same string, you could *prepend* this to the sed grammar:
s/YYerror/yyerror_token/g;
so that yyerror becomes acl_grammar_error, and YYerror become
acl_grammar_error_token. But of course next time we introduce another
symbol which differs by the case of the prefix, the problem will
be back.
Cheers!
Bug#689700: bison 2.6.2 generates incompatible header file
Hi, Maybe the following proposal went unnoticed. Le 19 oct. 2012 à 10:43, Akim Demaille a écrit : Nevertheless (I don't know Debian's schedule), there are a few bugs in 2.6.2 that have been fixed, and are scheduled to be released in 2.7 (say a couple of weeks). Would Debian folks like a 2.6.3 with just the bug fixes part of 2.7? I can prepare this quickly if you wish. Cheers! Akim -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#689700: bison 2.6.2 generates incompatible header file
Hi all!
Le 18 oct. 2012 à 17:53, Bill Allombert a écrit :
On Thu, Oct 18, 2012 at 02:15:38PM +0200, Akim Demaille wrote:
Hi Bill,
(and more to the point, Debian 'testing' includes bison 2.5 and
Debian 'unstable' includes bison 2.6 and some software in
'testing' does not build on 'unstable', but this is something for
the Debian maintainer to deal with.)
I'd be happy to help, as in the past, we also broke the backward
compatibility by fixing bugs in Bison that revealed incorrect code
in user code; this ended by fixing the code that was relying on a
bug in Bison.
The problem is that testing is frozen so this is not an option.
The real fix is to refrain from uploading new major version of bison to
unstable
during a freeze.
Well, now that Bison 2.6 is in, maybe the simplest is still
to fix incorrect uses? I might be mistaken, but I am under
the impression that we seem to converge on the idea that
Bison is rightful in its change (yet it does break some builds),
and there is no need to introduce workarounds in it.
Nevertheless (I don't know Debian's schedule), there are a
few bugs in 2.6.2 that have been fixed, and are scheduled
to be released in 2.7 (say a couple of weeks). Would Debian
folks like a 2.6.3 with just the bug fixes part of 2.7? I
can prepare this quickly if you wish.
By the way, the real package breaking is csound. The log is here:
https://buildd.debian.org/status/fetch.php?pkg=csoundarch=i386ver=1%3A5.17.11~dfsg-2stamp=1348960646
(I am not involved with csound in anyway, though)
Thanks for the pointer!
A way to fix the problem could be to add
#ifdef __cplusplus
extern C {
#endif
...
#ifdef __cplusplus
}
#endif
in the generated parse.tab.h.
This is not correct for people who do not want this guy to be
in extern C.
I agree, but I guess it is your turn to give an example that work with bison
2.5 and 2.6 but would not work with my change.
:)
You are preventing people to overload yyparse for instance.
Your suggestion is clearly a workaround to address the
situation at hand, but we both agree (that's my reading
for the end of your message) that that's not the way to
go in the long run, so I'd rather not introduce it and
face new bugs because of this.
As far as I see, this requires the user to build parse.tab.c with g++,
otherwise
parse() will have C linkage anyway. C++ requires prototypes, so the user
needs to
provide a prototype for parse() when using bison 2.5 at least.
When you allow to compile C files with a C++ compiler, it is customary to use
extern C, otherwise you ABI depend on the compiler.
But I quite understand why you would be wary of apply this change.
Maybe documenting to do
extern C {
#include parse.tab.h
}
in case of problem is the lesser evil.
I can suggest this, but I would have to draw the attention
of C++ programmers who use the C generated parser to pay
attention that then everything they define in their
parser must not rely on C++ mangling :/
I could leave such a note in a NEWS entry for 2.6.3, would
that suffice in your opinion?
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#689700: bison 2.6.2 generates incompatible header file
Hi Frank, Le 18 oct. 2012 à 18:52, Frank Heckenbach a écrit : We do compile our Bison output with g++ (yes, we should probably use the C++ skeleton, but we haven't gotten around to it yet), I'd be happy to give a hand, and get some feedback about it. and we don't use extern C -- in fact we use two different parsers in one executable and we put them in different C++ namespaces to avoid conflicts. (After the recent changes, this may no more be necessary as I understand, we'll have to check this after an upgrade …) Indeed, if you want both to be in the same namespace, %define api.prefix should do what you want. Note that the C++ output supports %define namespace, in which the generated code is put. Currently we have in our *.y: #define IN_BISON and in our common header: #ifndef IN_BISON int yyparse (params); #endif IIRC, with earlier Bisons, it worked without the #ifndef, now it produces a duplicate declaration, so I suppose that's the relevant change in Bison and our workaround. So I guess what this means is (a) blindly applying extern C would be wrong and (b) the situation is currently not nice, but acceptable (to us) with the above workaround, but at least that's temporary -- after dropping support for older Bisons, What is your policy on this regard? When do you allow to rise the %require'd version of Bison? (actually, currently I see none in http://csound.git.sourceforge.net/git/gitweb.cgi?p=csound/csound5.git;a=blob;f=Engine/csound_orc.y;h=259a4cbe6fd3873120513678f34b936103d2d43d;hb=HEAD) we won't have to declare yyparse at all which is (slightly) better than always having to declare it as it was before. Yes, indeed. Can the version of Csound compiled by Debian be changed easily to compile cleanly with Bison 2.6? -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
