-
Notifications
You must be signed in to change notification settings - Fork 534
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Unexpected symbol remapping macro definitions in 2.6.3 #162
Comments
Same problem when building grub. The definitions in question are under
See also https://savannah.gnu.org/bugs/?50093 |
This commit that apparently broke it is 347652c. Before this commit macros were expanded by m4; now it added |
This is now fixed on master and will be included in the next relase. Please confirm for your specific case. |
gdb master builds find with flex master. Could you mention which commit fixes this? Thanks a lot! |
should bwhat you want, but there are a couple others that are related/relevant. |
Current master fixes grub build as well. Thank you! |
I can confirm that master fixes KaZaA 2.3.7. Thanks! |
Given the wide impact, building with warnings treated as errors is common and distros like Arch Linux ship 2.6.3, can we please have a 2.6.4 soon that includes this fix. Thanks. |
Wireshark was affected as well by this change (maybe due to setting
|
With flex 2.6.3, this warning is observed (which causes a build failure when -Werror is not disabled: text2pcap-scanner.c:398:9: warning: 'yywrap' macro redefined [-Wmacro-redefined] #define yywrap() (/*CONSTCOND*/1) ^ text2pcap-scanner.c:76:13: note: previous definition is here #define yywrap yywrap Issue is specific to flex 2.6.3 and resolved upstream at westes/flex#162 Change-Id: I861565f5080f87a9457427e7a63b5d9256c49e85 Reviewed-on: https://code.wireshark.org/review/20294 Petri-Dish: Peter Wu <[email protected]> Reviewed-by: Michael Mann <[email protected]>
flex-2.6.3 is severly broken / incompatible see e.g. westes/flex#162
Another workaround.
|
There's no sign on westes/flex#162 that they will release a new flex with the fix soon.
Hey! It would be great to see a 2.6.4 that fixed this issue released. Any chance of that? |
Yes it's in my queue to get this out.
…On Friday, 7 April 2017, 9:50 am -0700, "Perry E. Metzger" ***@***.***> wrote:
Hey! It would be great to see a 2.6.4 that fixed this issue released. Any chance of that?
--
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
#162 (comment)
--
Will Estes
[email protected]
|
Thank you! Meanwhile, I have a couple of broken ports in macports because I pulled in 2.6.3, can you tell me what patches I need to apply to fix this? f5d87f1 didn't seem to do it on its own. |
MacPorts maintainer of wine and flex here. No idea what we need to do so that wine can compile again. I added a patch for f5d87f1 at Perry's suggestion, but that doesn't fix it. If flex 2.6.4 will fix it, please release it now. |
@ryandesign it is already done unofficially: |
It needs to be on https://github.com/westes/flex/releases |
@ryandesign Have you seen #162 (comment) above? |
@ryandesign no shit, but it is currently NOT there, so deal with it. The owner is quite aware that a new release is needed |
Hi @svnpenn, We've had three months of projects stumbling over this problem and having to work out the cause and hopefully end up here. That's quite a bit of, often volunteer, manpower. As it has such widespread impact, and a simple fix, I think it warranted a 2.6.4 that fixed nothing but this if it meant it got out the door quickly. I see other projects make quick releases a few days later on the info-gnu mailing list when some simple mistake with wide impact slipped through. I realise flex's maintainer is also a volunteer, and we're all short of time, but I find the amplification of wasted effort a bit saddening. |
Meanwhile, does anyone know the exact set of patches that deal with this issue, given that it wasn't just that one? |
That would cause confusion. 2.6.4 is coming and quickly.
If you need something right now, then grab the tip of master.
…On Friday, 21 April 2017, 5:52 am -0700, "Perry E. Metzger" ***@***.***> wrote:
Perhaps someone should create an unofficial 2.6.4 in another Github repository until such time as @westes has the time to create an official 2.6.5. @westes, would you be okay with that?
--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
#162 (comment)
--
Will Estes
[email protected]
|
Hi @pmetzger, That wouldn't work as all the distros look to westes for the next release; they wouldn't switch away and back. It would be easier to get some of them, e.g. Debian, to fix locally if they haven't already. But some distros don't tinker, e.g. Arch Linux, and other people take the latest official release direct. |
The problem is that there isn't an obvious set of patches to apply to fix the issue locally. If someone would package up the several patches apparently needed to deal with this problem, then it should be possible for people to apply them locally in the various places that they're needed while we are waiting for 2.6.4. That would be greatly appreciated. |
(Just to explain why a set of patches for this one issue is better: grabbing the tip of the master isn't feasible for Linux distributions, MacPorts, etc.) |
* grab 2.6.3
* Unpack flex-2.6.3
* grab tip of master
* unpack tip of master in a separate tree from 2.6.3
* ./autogen.sh
* diff
Then you have a patch.
If you need one, that's how to do it.
…On Friday, 21 April 2017, 6:32 am -0700, "Perry E. Metzger" ***@***.***> wrote:
(Just to explain why a set of patches for this one issue is better: grabbing the tip of the master isn't feasible for Linux distributions, MacPorts, etc.)
--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
#162 (comment)
--
Will Estes
[email protected]
|
Most projects (like Debian, say), by policy, can't add large patches like that. For example, in MacPorts, you need to create a patchfile per file and bug that you are fixing and you're supposed to be relatively minimalist about what you do. Debian is even stricter IIRC. It would be useful to get just the patches for this particular bug and not all the other things that have changed. |
The commit messages are pretty good. You've been pointed to the relevant issues and pull requests. You have enough information to assemble the patches you need if you want a minimalist patch. I've told you how to just grab everything as well.
…On Friday, 21 April 2017, 7:05 am -0700, "Perry E. Metzger" ***@***.***> wrote:
Most projects (like Debian, say), by policy, can't add large patches like that. For example, in MacPorts, you need to create a patchfile per file and bug that you are fixing and you're supposed to be relatively minimalist about what you do. Debian is even stricter IIRC. It would be useful to get _just_ the patches for this particular bug and not all the other things that have changed.
--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
#162 (comment)
--
Will Estes
[email protected]
|
The commit messages seemed good enough, except that I didn't manage to figure out what I wanted from them, since I'm not a domain expert on Flex. So, I asked the project maintainer for assistance. I get that you're a volunteer. So are almost all of us maintaining downstream package and operating system distributions. I understand that you doubtless have competing interests, commitments, etc. and I know what it is like for them to get in the way. |
@pmetzger how about you drop it? He has said repeatedly that he is working on it. Unless you are paying him, you have no say and no control over his time. This is open source, not nag-source. |
@svnpenn, Please make your points more politely as it doesn't help to have anything that could raise the temperature. |
Ralph, your comment is out of line and therefore void. You have no voice in the governance of the flex project. Quit pretending that you do.
@svnpenn spoke correctly. Flex is open source, not nag source.
To state the current situation clearly so that there is no room for misunderstanding: Stop discussing this topic. Any time that I have to spend on this thread takes away from the limited time that I have to getting the next release of flex.
…On Friday, 21 April 2017, 9:24 am -0700, RalphCorderoy ***@***.***> wrote:
@svnpenn, Please make your points more politely as it doesn't help to have anything that could raise the temperature.
--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
#162 (comment)
--
Will Estes
[email protected]
|
@westes He was merely, politely, asking someone to be polite. I think that's always reasonable. Cool heads and polite discussion always beats raising the temperature. |
Stop your nagging. You have the information you requested. Pretending to have authority that he does not have is lying, which is not polite. Supporting him, as you are doing, is also not polite.
To repeat my earlier point: Time I have to spend on this closed thread is time I do not have to spend on putting out the next flex release. If you were telling the truth about wanting that release, then stop wasting my time by commenting on this or any other flex related thread.
…On Friday, 21 April 2017, 9:54 am -0700, "Perry E. Metzger" ***@***.***> wrote:
@westes He was merely, politely, asking someone to be polite. I think that's always reasonable. Cool heads and polite discussion always beats raising the temperature.
--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
#162 (comment)
--
Will Estes
[email protected]
|
Hi @westes, My request that points of view be made politely to avoid being inflammatory is not out of line; it now seems apposite. I have never pretended to have a voice in the governance in the flex project, but merely been a participant on this bug report, including trying to help others by giving a workaround and pointing newcomers to it. |
Lying to support your previous pretense at authority is stupid.
Stand down. Now. That is your final warning.
…On Friday, 21 April 2017, 10:23 am -0700, RalphCorderoy ***@***.***> wrote:
Hi @westes, My request that points of view be made politely to avoid being inflammatory is not out of line; it now seems apposite. I have never pretended to have a voice in the governance in the flex project, but merely been a participant on this bug report, including trying to help others by giving a workaround and pointing newcomers to it.
--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
#162 (comment)
--
Will Estes
[email protected]
|
What have you done @simark! |
So for now, MacPorts has moved back to 2.6.1, and what I'd suggest to others with the same issue is that those distributions and package collections that need a version that doesn't have the bug can do that while they are waiting for 2.6.4 to come out. |
@pmetzger thats pretty dumb. Just do the sane thing and build off master, like we did: http://cygwin.com/ml/cygwin/2017-04/msg00204.html Not sure why your world has to fall apart when a package goes too long without a point release, but that is your issue not ours. I have had about enough of you and @RalphCorderoy whining about this already. Stop crying, do a master build, and move on until an actual release is made. You quite pissed off the owner and that certainly doesnt bode well for future releases. |
I don't think advising to build off of master is advisable either, as it could suffer from more regressions, and is of course a moving target. While a new tag should be made, there's no rush, just use a previous release. That should've happened earlier anyway, when it was realized it broke several packages within a build environment. |
@austin987 Yah, we should have backed out earlier, but you live and learn. Anyway, we're fine now. And of course, you've mentioned precisely why we tend not to use non-releases. Many projects have hard rules against it except in unusual circumstances. |
Anyway, Will, I'm sorry if any of this caused acrimony. I was trying to avoid a fight, not to have one. All is well now regardless. |
Include comments with the version numbers this will blow up before; I choose to completely ignore the issue until somebody shows up with a >22 year old version of flex. The latter will probably clean up some build warnings on some platforms. The former may do the same, and additionally sidesteps a bug in flex 2.6.3 that lead to the macro being defined and causing troubles when it tried to link since it couldn't find yywrap() (our faked version not being added due to the #ifdef). x-ref <westes/flex#162>
Hello,
My question originates from the fact that current gdb master doesn't build with flex 2.6.3:
https://sourceware.org/bugzilla/show_bug.cgi?id=21057
I noticed that flex now defines the macros to do symbol remapping even though the -P switch (to change the prefix of symbols) is not given.
With flex 2.6.2, omitting -P would not emit those symbols. Using -P would add them:
With 2.6.3, those defines are there even without -P:
Our problem is that GDB does its own remapping of the symbols by defining those same macros, in order to integrate multiple lexers/parsers.
See: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=blob;f=gdb/yy-remap.h;h=09b0a892d4e416df5098f6a527a86909e279b0bf;hb=HEAD
and an example usage of that file: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=blob;f=gdb/c-exp.y;h=8a92cce0ab3fa903e7a0466f35dfe2e177405deb;hb=HEAD#l59
So when trying to build, there is a clash between the gdb-defined macros
and the flex-defined macross
Here is my question: was this change of behaviour (to output those defines event without -P) done on purpose?
In any case, I suppose we should be using -P instead of making our own defines, is that right?
The text was updated successfully, but these errors were encountered: