Bug#689700: bison 2.6.2 generates incompatible header file
On Mon, Oct 29, 2012 at 11:59:50AM -0700, Chuan-kai Lin wrote: Bill, bison 2.6.4 is out at http://ftp.gnu.org/gnu/bison/ - can you check if the new version fixes this bug? I do not think there is any expectation that bison 2.6.4 fix this bug. On the other hand, Felipe Sateler has raised the severity due to a different problem. So the severity of 689700 should be reset to normal, and Felipe should report his problem in a separate bug report unless the problem has already been adressed. Cheers, -- Bill. ballo...@debian.org Imagine a large red swirl here. -- To UNSUBSCRIBE, email to debian-bugs-dist-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
severity 689700 normal clone 689700 -1 retitle -1 Downgrade to version 2.4 until wheezy is released severity -1 serious thanks On Wed, Oct 31, 2012 at 8:06 AM, Bill Allombert bill.allomb...@math.u-bordeaux1.fr wrote: On Mon, Oct 29, 2012 at 11:59:50AM -0700, Chuan-kai Lin wrote: Bill, bison 2.6.4 is out at http://ftp.gnu.org/gnu/bison/ - can you check if the new version fixes this bug? I do not think there is any expectation that bison 2.6.4 fix this bug. On the other hand, Felipe Sateler has raised the severity due to a different problem. So the severity of 689700 should be reset to normal, and Felipe should report his problem in a separate bug report unless the problem has already been adressed. I agree. Severity reset and cloned. -- Saludos, Felipe Sateler -- To UNSUBSCRIBE, email to debian-bugs-dist-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
Bill, bison 2.6.4 is out at http://ftp.gnu.org/gnu/bison/ - can you check if the new version fixes this bug? Thanks, -- To UNSUBSCRIBE, email to debian-bugs-dist-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, 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-dist-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
On Sun, Oct 21, 2012 at 9:24 AM, Akim Demaille a...@lrde.epita.fr wrote: 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. Yes, we would really like to have a 2.6.3 bug-fix release. Cheers! Akim -- To UNSUBSCRIBE, email to debian-bugs-dist-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-dist-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-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#689700: *** GMX Spamverdacht *** Re: bison 2.6.2 generates incompatible header file
Akim Demaille wrote: 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. Thanks, seems like we have several viable options here. (Though I'd have to check what about flex -- I haven't followed it recently, and of course, both parsers need different scanners.) 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? I'm not part of the Csound team (if you understood that), I was just replying to the question about an example which we have in our (unrelated) project. FWIW, our support policy is basically Debian oldstable, so we'll probably drop support for Bison 2.4.1 early next year. About the C++ skeleton, I'm currently busy with other tasks, but when I get around to it and encounter any issues, I'll post on bug-bison (would have anyway :-). Frank -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#689700:
Sorry for the late reply, your mail was eaten by my spam filter. On Sun, Oct 14, 2012 at 9:09 AM, Bill Allombert bill.allomb...@math.u-bordeaux1.fr wrote: On Sat, Oct 13, 2012 at 05:18:48PM -0700, Chuan-kai Lin wrote: On Sat, Oct 13, 2012 at 3:35 PM, Felipe Sateler fsate...@debian.org wrote: This causes unrelated packages to break. Please revert this change until wheezy is released, since it makes fixing bugs in testing harder than necessary for pacakges build-depending on bison. Hello Felipe, Could you provide example of such packages for the record ? I found the problem with the pari package, but it is not normally build with g++ so it does not affect Debian, hence the severity. Yes, my package csound fails to build for this reason, and is preventing a bugfix to migrate to testing. -- Saludos, Felipe Sateler -- To UNSUBSCRIBE, email to debian-bugs-dist-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
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.
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)
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.
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.
Cheers,
--
Bill. ballo...@debian.org
Imagine a large red swirl here.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#689700: *** GMX Spamverdacht *** Re: *** GMX Spamverdacht *** Re: bison 2.6.2 generates incompatible header file
PS: Bill Allombert wrote: 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. It probably does, but for us that's not relevant since we compile everything with GCC anyway. Frank -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#689700: *** GMX Spamverdacht *** Re: bison 2.6.2 generates incompatible header file
Bill Allombert wrote:
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.
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.
FWIW (not sure if it's a relevant example, since I haven't tried
with the newer Bison versions yet; we use the one in squeeze):
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), 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 ...)
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, we won't have to declare
yyparse at all which is (slightly) better than always having to
declare it as it was before.
Frank
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#689700: *** GMX Spamverdacht *** Re: bison 2.6.2 generates incompatible header file
On Thu, Oct 18, 2012 at 06:52:41PM +0200, Frank Heckenbach wrote: Bill Allombert wrote: 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), 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 ...) How do you put them in separate namespace ? Cheers, Bill. -- To UNSUBSCRIBE, email to debian-bugs-dist-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
Bill Allombert wrote:
On Thu, Oct 18, 2012 at 06:52:41PM +0200, Frank Heckenbach wrote:
Bill Allombert wrote:
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), 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 ...)
How do you put them in separate namespace ?
foo.y:
%{
#define IN_BISON
#include foo.h
namespace foo
{
// some declarations, including yyerror
%}
// grammar and everything
%%
}
foo.h:
#include ...
namespace foo
{
// various other declarations
#ifndef IN_BISON
int yyparse (...);
#endif
}
Not sure if it's supposed to work like this, but currently it does. :)
Frank
--
To UNSUBSCRIBE, email to debian-bugs-dist-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
On Wed, Oct 17, 2012 at 11:00:49AM -0700, Chuan-kai Lin wrote: Hi, I am forwarding this bug report by Bill Allombert from the Debian bug tracking system (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=689700). Here is Bill's report: Dear bison developers, I realise my report was incomplete. Please find a test case in attachment. bison 2.4.1: bison -d parse.y gcc -c parse.tab.c -o parse.tab.o g++ proj.c parse.tab.o -o proj bison 2.6.2: bison -d parse.y gcc -c parse.tab.c -o parse.tab.o g++ proj.c parse.tab.o -o proj In file included from proj.c:1:0: parse.tab.h:62:5: error: previous declaration of ‘int yyparse()’ with ‘C++’ linkage In file included from proj.c:2:0: proj.h:4:18: error: conflicts with new declaration with ‘C’ linkage make: *** [all] Erreur 1 Cheers, -- Bill. ballo...@debian.org Imagine a large red swirl here. proj.tgz Description: GNU Unix tar archive
Bug#689700:
On Sat, Oct 13, 2012 at 05:18:48PM -0700, Chuan-kai Lin wrote: On Sat, Oct 13, 2012 at 3:35 PM, Felipe Sateler fsate...@debian.org wrote: This causes unrelated packages to break. Please revert this change until wheezy is released, since it makes fixing bugs in testing harder than necessary for pacakges build-depending on bison. Hello Felipe, Could you provide example of such packages for the record ? I found the problem with the pari package, but it is not normally build with g++ so it does not affect Debian, hence the severity. Do you happen to know what is the correct procedure to revert the introduction of a new upstream release? Is it something that the release team can handle through a bug to release.debian.org? Hello Chuan-kai Did you report the bug upstream ? Maybe they could provide a fix. The only way to revert to an older upstream release is to reupload the old upstream release with a larger version number, either by raising the epoch field of by playing game like 2.6.2.really.2.5.0. It is generally not recommended to upload new upstream version during the freeze especially if they hae a large number of reverse dependencies or build-dependencies. Cheers, -- Bill. ballo...@debian.org Imagine a large red swirl here. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#689700:
On Sat, Oct 13, 2012 at 9:18 PM, Chuan-kai Lin chk...@gmail.com wrote: On Sat, Oct 13, 2012 at 3:35 PM, Felipe Sateler fsate...@debian.org wrote: This causes unrelated packages to break. Please revert this change until wheezy is released, since it makes fixing bugs in testing harder than necessary for pacakges build-depending on bison. Do you happen to know what is the correct procedure to revert the introduction of a new upstream release? Is it something that the release team can handle through a bug to release.debian.org? No, I don't think the RT can do that. I think there are only 3 options: 1. Ignore this bug (not what I'd like) 2. Upload the old version again with an increased epoch (like 2:2.5.dfsg-1) 3. Upload the old version with a version like 1:2.6.2.dfsg+really2.5-1 I'm not sure if there is a correct procedure, I've seen both 2 and 3 done. -- Saludos, Felipe Sateler -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#689700:
Control: severity -1 serious Bill Alombert wrote: This is unfortunate because this does not necessarily declare int parse (char **lex) in the right C++ namespace, causing conflict with the user supplied prototype (which is certainly necessary with older releases), causing compilation error. This causes unrelated packages to break. Please revert this change until wheezy is released, since it makes fixing bugs in testing harder than necessary for pacakges build-depending on bison. -- Saludos, Felipe Sateler -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#689700:
On Sat, Oct 13, 2012 at 3:35 PM, Felipe Sateler fsate...@debian.org wrote: This causes unrelated packages to break. Please revert this change until wheezy is released, since it makes fixing bugs in testing harder than necessary for pacakges build-depending on bison. Do you happen to know what is the correct procedure to revert the introduction of a new upstream release? Is it something that the release team can handle through a bug to release.debian.org? -- Chuan-kai Lin http://sites.google.com/site/chklin/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#689700: bison: generate incompatible header file
Package: bison
Version: 1:2.6.2.dfsg-1
Severity: normal
Hello Chuan-kai,
This version of bison -d parse.y generates a parse.h ending file with the
following
(assuming the file contain
%parse-param {char **lex}
)
#ifdef YYPARSE_PARAM
#if defined __STDC__ || defined __cplusplus
int parse (void *YYPARSE_PARAM);
#else
int parse ();
#endif
#else /* ! YYPARSE_PARAM */
#if defined __STDC__ || defined __cplusplus
int parse (char **lex);
#else
int parse ();
#endif
This was not done in bison 2.4.1 and earlier release, and as far as I can see
this
change is not documented anywere.
This is unfortunate because this does not necessarily declare int parse (char
**lex)
in the right C++ namespace, causing conflict with the user supplied prototype
(which is certainly necessary with older releases), causing compilation error.
Cheers,
--
Bill. ballo...@debian.org
Imagine a large red swirl here.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
