-
Notifications
You must be signed in to change notification settings - Fork 448
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
Some fixes for modern Arch Linux, bison and gcc 14 #51
base: master
Are you sure you want to change the base?
Conversation
'bison -y' is default emulation for yacc on linux and this spits out warnings that %term is not supported. So don't use emulation mode of yacc but bison instead. Default output file is bison.gram.c, set it to y.gram.c Signed-off-by: Andreas J. Reichel <[email protected]>
main is supposed to be 'int' Signed-off-by: Andreas J. Reichel <[email protected]>
gram.c is generated by BISON and should not be in the source tree. Signed-off-by: Andreas J. Reichel <[email protected]>
Its a C89 compiler that was built with C89 standard so shouldn't this be compiled with std=gnu89 or -ansi instead of adding the int return type to main. |
why... default on current distros should work... and this is surely not C89. What the conpiled compiler understands is independent of what the compiler used to compile the compiler understands.
Am 4. Februar 2025 20:07:56 MEZ schrieb bret-walda ***@***.***>:
…Its a C89 compiler that was built with C89 standard so shouldn't this be compiled with std=gnu89 or -ansi instead of adding the int return type to main.
--
Reply to this email directly or view it on GitHub:
#51 (comment)
You are receiving this because you authored the thread.
Message ID: ***@***.***>
|
I am just asking here but if i already have a compiled version of lcc and try to bootstrap it wouldn't this cause issues with the int being explicit now or am i just being dense i have tried to compile some older programs that used this and they wouldn't compile unless i added the gnu89 flag. The compiler says it is C89 compliant shouldn't the compiler also adhere to it and be built using the standard. I am just trying to understand the thought process here. Thanks in advance for bearing with me. |
no, that's fine in both C89 and newer standards. so using the version that works with any seems preferable. though having watched this repo for the past decade filing a PR here is a waste of time if one wants to get it merged... |
So i must be confusing C89 with K&R version and thanks for clearing up the confusion. Yup figured since it is also tied to their book and they might be happy with how far it has come and don't want to update it anymore but you have been watching this repo for the past decade must be the OG cracked c programmer. |
it's more a matter of clicking the watch repo button here on github to get notified of anything happening here... |
I found this repo not long ago and was equally impressed as John Carmack... Only a few people notice how great this is regarding retargetability and understandability... even to integrate your own VM into your code and compile with this 😇
Am 5. Februar 2025 15:06:30 MEZ schrieb rofl0r ***@***.***>:
…> but you have been watching this repo for the past decade must be the OG cracked c programmer.
it's more a matter of clicking the watch repo button here on github to get notified of anything happening here...
--
Reply to this email directly or view it on GitHub:
#51 (comment)
You are receiving this because you authored the thread.
Message ID: ***@***.***>
|
Here are some suggestions to make it work on modern Linux with:
There are two fixes regarding gcc 14.1.1:
I included an example build script for linux since this was not so straight forward for me to understand, how to compile it.
It also takes care of using "bison" instead of "bison -y" because "bison -y" gives warnings about not supporting "%term".
Furthermore,
gram.c
is generated and should hence not be in the git.