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=csound&arch=i386&ver=1%3A5.17.11~dfsg-2&stamp=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
