5
3
Fork
You've already forked libfx2
0

SDCC 4.2.9/4.3.0+ fixes #13

Closed
vifino wants to merge 0 commits from sdcc-430-fixes into main
pull from: sdcc-430-fixes
merge into: GlasgowEmbedded:main
GlasgowEmbedded:main
vifino commented 2023年11月05日 16:23:22 +01:00 (Migrated from github.com)
Copy link

I've fixed the build for libfx2 with new SDCC versions.
This fixes #11.

In addition, I've also made all functions that take no arguments declare a proper prototype.
This silences sdcc compiler warning 283 and makes the code more correct.

I tested with SDCC 4.2.0 and SDCC 4.3.0.

I've fixed the build for libfx2 with new SDCC versions. This fixes #11. In addition, I've also made all functions that take no arguments declare a proper prototype. This silences sdcc compiler warning 283 and makes the code more correct. I tested with SDCC 4.2.0 and SDCC 4.3.0.

That is cursed as hell. How is requiring this not a bug in sdcc?..

That is cursed as hell. How is requiring this not a bug in sdcc?..
whitequark left a comment
Copy link

Happy to merge the prototype fix of course, the -MF one I'm less sure about.

Happy to merge the prototype fix of course, the -MF one I'm less sure about.
vifino (Migrated from github.com) reviewed 2023年11月06日 10:27:00 +01:00
vifino (Migrated from github.com) commented 2023年11月06日 10:27:00 +01:00
Copy link

I wish I knew. All I have to go on is this mailing list thread. And trying to build it, of course.

Phillip mentioned the reason:

AFAIK, since GCC 3,
this should be -MMD -MF build/main.d instead.
Current SDCC has rebased its GCC preprocessor fork on a newer upstream
version, and apparently GCC has since dropped the pre-GCC-3
compatibility syntax, and so did SDCC.

Contrary to what Phillip said in the rest of the message -

I haven't tried it, but I think
-MMD -MF build/main.d should work both with current SDCC and any older
SDCC from the last 15 years or so.

This does not work with SDCC 4.2.0, so I doubt it works with older versions.
Looking in the manual in Section 1.5 Compatibility with previous versions, there is the following line:

In 4.2.9, support for arguments to -MMD was dropped. The output file can be specified via -MF instead.

There is an alternative fix suggested by Felix -

You can pass both -MMD and -MQ directly to sdcc of either version, there
is no need for -Wp, if you can afford a second pass.

Try

$ sdcc -MQ .rel -MMD build/foo.c -o build/foo.d

Look at build/foo.d.

But I didn't manage to make it work without digging deep into the Makefile. Sorry!
I settled for the version check as the least intrusive fix (as I gave up on the other).

Further along in the mailing list, the reason for the rebasing and the need for the prototype fix is to work towards ISO C2X compliance.

I wish I knew. All I have to go on is [this mailing list thread](https://sourceforge.net/p/sdcc/mailman/sdcc-devel/thread/CAGjSPUDLCihL71_fv0Px4Ws_sa4E21Pq6yF0%2B6MSsecUFf-c1g%40mail.gmail.com/#msg37851015). And trying to build it, of course. Phillip mentioned the reason: > AFAIK, since GCC 3, this should be `-MMD -MF build/main.d` instead. Current SDCC has rebased its GCC preprocessor fork on a newer upstream version, and apparently GCC has since dropped the pre-GCC-3 compatibility syntax, and so did SDCC. Contrary to what Phillip said in the rest of the message - > I haven't tried it, but I think `-MMD -MF build/main.d` should work both with current SDCC and any older SDCC from the last 15 years or so. This does not work with SDCC 4.2.0, so I doubt it works with older versions. Looking in [the manual](https://sdcc.sourceforge.net/doc/sdccman.pdf) in Section 1.5 Compatibility with previous versions, there is the following line: > In 4.2.9, support for arguments to -MMD was dropped. The output file can be specified via -MF instead. There is an alternative fix suggested by Felix - > You can pass both -MMD and -MQ directly to sdcc of either version, there > is no need for -Wp, if you can afford a second pass. > > Try > > $ sdcc -MQ .rel -MMD build/foo.c -o build/foo.d > > Look at build/foo.d. But I didn't manage to make it work without digging deep into the Makefile. Sorry! I settled for the version check as the least intrusive fix (as I gave up on the other). Further along in the mailing list, the reason for the rebasing and the need for the prototype fix is to work towards ISO C2X compliance.

I cherry-picked 28b6557 (the prototype fix) which is fine. I then tried to rebase this PR on main so that only the other commit is left for discussion, but failed and unintentionally closed the PR.

I would like to see a fix not involving sdcc version sniffing.

I cherry-picked [28b6557](https://github.com/whitequark/libfx2/pull/13/commits/28b65576caf03d5dd45ac94514fd54b613765b75) (the prototype fix) which is fine. I then tried to rebase this PR on main so that only the other commit is left for discussion, but failed and unintentionally closed the PR. I would like to see a fix not involving sdcc version sniffing.

Pull request closed

This pull request cannot be reopened because the branch was deleted.
Sign in to join this conversation.
No reviewers
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
2 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
GlasgowEmbedded/libfx2!13
Reference in a new issue
GlasgowEmbedded/libfx2
No description provided.
Delete branch "sdcc-430-fixes"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?