-
Notifications
You must be signed in to change notification settings - Fork 39
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
Build is broken for ia16 gcc #79
Comments
Hello @andrewbird, The main difference seems to be that my Perhaps you can try adding return values to FreeCOM's versions of these functions as well — both in the declarations and definitions — so that the prototypes will agree with those from Thank you! |
Hello @tkchia, Thank you! |
Hello all, Here is my proposed patch:
Thank you! |
Hello @tkchia, Thanks again! |
Hello @andrewbird,
The functions were only available through In newer versions (~ June 2022) of Thank you! |
Hello @tkchia , sorry I didn't explain very well. I meant why didn't watcom's compilation fail? |
Hello @andrewbird, Oh. Apparently the problematic declarations were only included if
so the conflicting declarations and definitions were not included when using Open Watcom. (I suppose, if you want to, you could also try to distinguish between "early" and "later" versions of
etc. might work, though I have not tested this.) Thank you! |
Hello @tkchia, Many thanks! |
Since ia16-elf-gcc's libi86 received support for fmemcpy, fmemmove and fmemset, its prototypes are in conflict with the replacement functions defined in the suppl directory. If libi86 implements all of the support required for FreeCOM in the future, then we may not need to include suppl, but until then adjust the suppl to match the common prototypes. Patch by @tkchia, and discussion at [fixes FDOS#79]
Since ia16-elf-gcc's libi86 received support for fmemcpy, fmemmove and fmemset, its prototypes are in conflict with the replacement functions defined in the suppl directory. If libi86 implements all of the support required for FreeCOM in the future, then we may not need to include suppl, but until then adjust the suppl to match the common prototypes. Patch by @tkchia, and discussion at [fixes #79]
I presume this is because @tkchia's libi86 now has support for fmem functions. I'm not sure what the correct fix is here though.
The text was updated successfully, but these errors were encountered: