Skip to content
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

fix building old gcc with new gcc by using -std=gnu89 #3

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

urjaman
Copy link

@urjaman urjaman commented Aug 27, 2016

I've been building some of these on arch. Not sure if this is everything thats needed for the gcc-539 ...
(i needed to build an older bison and set that in the path for something, but cant remember if it was for this.)

@mstorsjo
Copy link
Owner

I tried building gcc-539 with GCC 6 (on debian sid), and it seemed to work fine without this patch, so it seems it's probably not needed after all? (I guess GCC 6 is the version where the default language was changed.)

I'll try to do a clean docker test build env to verify that these things still build with recent tools...

@urjaman
Copy link
Author

urjaman commented Aug 29, 2016

I think the default was changed atleast already in gcc 5, but the symptom was that I'd get
a c-lex.c:273: undefined reference to `is_reserved_word' and searching for that found people trying to compile an old 2.95 gcc with gcc 5.4.0 and the response was to use -std=gnu89, and it worked.

At first i thought it was debian doing weird stuff, but a "quck" test of getting a gcc 6 on debian shows that yeah they didnt mess with gcc like that... dunno what it exactly is then.

@mstorsjo
Copy link
Owner

Hmm, ok.

When trying to rebuild all of this on modern debian sid, I'm now running into issues with building the codesourcery GCC (3.4) with modern bison, failing on something like this:

c-parse.y: In function 'yyparse':
c-parse.y:594:16: error: 'YYLEX' undeclared (first use in this function)
       yychar = YYLEX;

Was this something that you happened to have seen? It seems like it could be caused by a too new bison version.

@urjaman
Copy link
Author

urjaman commented Aug 29, 2016

Yes I have built that gcc 3.4 and I have as a workaround installed a bison 2.7.12-4996 in my personal ~/bin and set that first in the path, but obviously that isnt a very good solution.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants