| Summary: | dev-embedded/openocd fails to compile with -fno-common or gcc-10 | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Agostino Sarubbo <ago> |
| Component: | Current packages | Assignee: | Embedded Gentoo Team <embedded> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | fercerpav, kripton, sam |
| Priority: | Normal | Keywords: | PullRequest |
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| See Also: |
https://github.com/gentoo/gentoo/pull/18722 https://bugs.gentoo.org/show_bug.cgi?id=763855 |
||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | |||
| Bug Blocks: | 705764 | ||
| Attachments: | build.log | ||
Created attachment 638384 [details]
build.log
build log and emerge --info
Fixed upstream with http://openocd.zylin.com/#/c/5592/ . Packaging current master instead of the old release is recommended. I've created a PR that adds the patch from upstream on top of 0.10.0. @Paul Fertser: According to the package's metadata you are the maintainer. Would you mind giving the PR a review? Thanks! Hello, Please consider packaging 0.11.0-rc1 instead (there're new optional but recommended dependencies, especially libgpiod; adding a capstone useflag might be appropriate too). The patch to fix compilation error from upstream is of course appropriate if you decided not to. (In reply to jannis from comment #3) > I've created a PR that adds the patch from upstream on top of 0.10.0. @Paul > Fertser: According to the package's metadata you are the maintainer. Would > you mind giving the PR a review? Thanks! For the reference, I'm listed in the maintainers just to receive all related notifications automatically; I do not have any decent experience writing and maintaining ebuilds, so can't give a good advice there, sorry. It seems odd that the whole ebuild contents needs to be duplicated, feels like a violation of DRY. > For the reference, I'm listed in the maintainers just to receive all related > notifications automatically; I do not have any decent experience writing and > maintaining ebuilds, so can't give a good advice there, sorry. Sure, no problem, I was unaware of that :) > It seems odd > that the whole ebuild contents needs to be duplicated, feels like a > violation of DRY. Well, that's how you see it. I could've also modified the ebuild of 0.10.0-r1. But since that wasn't written by me, I'd rather not touch that. Instead, if the patch and PR is fine, the maintainer (dev-embedded crew) can drop 0.10.0-r1 afterwards and we're good, no repetition. (In reply to Paul Fertser from comment #4) > Please consider packaging 0.11.0-rc1 instead (there're new optional but > recommended dependencies, especially libgpiod; adding a capstone useflag > might be appropriate too). I'm currently preparing the ebuild for 0.11.0_rc1. Regarding the capstone USE-flag: How do I enable/disable support for that? I don't see a --(en/dis)able-capstone flag in the output of ./configure --help Since I currently don't have any hardware to test on, would you be able to do some basic tests once the ebuild is ready? (In reply to jannis from comment #7) > Regarding the capstone USE-flag: How do I enable/disable support for that? I > don't see a --(en/dis)able-capstone flag in the output of ./configure --help Currently if pkg-config reports that "capstone" is available then it gets used for ARM disassembler, otherwise OpenOCD omits the support for integrated facility to disassemble ARM/Thumb altogether. > Since I currently don't have any hardware to test on, would you be able to > do some basic tests once the ebuild is ready? I hope so. (In reply to Paul Fertser from comment #8) > Currently if pkg-config reports that "capstone" is available then it gets > used for ARM disassembler, otherwise OpenOCD omits the support for > integrated facility to disassemble ARM/Thumb altogether. Hm, that sounds like an automagic dependency to me, then. Could you please introduce a configure switch for that in the next rc? The problem is described in detail by a person far more experienced in ebuild writing than me here: https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Automagic_dependencies Thanks :) Or is "capstone" a binary/external process that you spawn instead of a library that you link agianst? In that case, one could make it an optional dependency or hint the user in a post-merge info message (as done here: https://github.com/gentoo/gentoo/blob/master/sys-process/glances/glances-3.1.5.ebuild#L58) (In reply to jannis from comment #9) > (In reply to Paul Fertser from comment #8) > > Currently if pkg-config reports that "capstone" is available then it gets > > used for ARM disassembler, otherwise OpenOCD omits the support for > > integrated facility to disassemble ARM/Thumb altogether. > > Hm, that sounds like an automagic dependency to me, then. Could you please > introduce a configure switch for that in the next rc? You're right, thank you for the clarification. http://openocd.zylin.com/#/c/5985/ should help with that. (In reply to Paul Fertser from comment #11) > You're right, thank you for the clarification. > http://openocd.zylin.com/#/c/5985/ should help with that. Thanks, that change looks good to me :) I'm looking forward to the next rc or release. Please ping me here once it is out. I'll make a PR for the 0.11.x ebuild then. (In reply to jannis from comment #12) > (In reply to Paul Fertser from comment #11) > > You're right, thank you for the clarification. > > http://openocd.zylin.com/#/c/5985/ should help with that. > > Thanks, that change looks good to me :) > I'm looking forward to the next rc or release. Please ping me here once it > is out. I'll make a PR for the 0.11.x ebuild then. Please consider packaging -rc1 in the mean time, chances are that some other problem would be found that way, and we'd have fewer release candidates before the final. The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=932966d8e53c771d30e0eebbc12a9b6256f81ce9 commit 932966d8e53c771d30e0eebbc12a9b6256f81ce9 Author: Jannis Achstetter <kripton@kripserver.net> AuthorDate: 2020-12-19 09:26:41 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2020-12-27 05:01:04 +0000 dev-embedded/openocd: Fix compilation with gcc 10 Closes: https://bugs.gentoo.org/722640 Package-Manager: Portage-3.0.12, Repoman-3.0.2 Signed-off-by: Jannis Achstetter <kripton@kripserver.net> Closes: https://github.com/gentoo/gentoo/pull/18722 Signed-off-by: Sam James <sam@gentoo.org> .../openocd/files/openocd-0.10.0-gcc10.patch | 36 ++++++++++++++++++++++ dev-embedded/openocd/openocd-0.10.0-r1.ebuild | 4 +++ 2 files changed, 40 insertions(+) The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=45de522eb99a6a1cc619ffb1f69b748133da347b commit 45de522eb99a6a1cc619ffb1f69b748133da347b Author: Jakov Smolic <jakov.smolic@sartura.hr> AuthorDate: 2020-12-28 14:15:33 +0000 Commit: David Seifert <soap@gentoo.org> CommitDate: 2020-12-28 14:15:33 +0000 dev-embedded/openocd: Fix build with gcc-10 * Drop unused eclasses Closes: https://bugs.gentoo.org/722640 Package-Manager: Portage-3.0.9, Repoman-3.0.1 Signed-off-by: Jakov Smolic <jakov.smolic@sartura.hr> Signed-off-by: David Seifert <soap@gentoo.org> .../openocd/files/openocd-0.10.0-fno-common.patch | 11 ++ dev-embedded/openocd/openocd-0.10.0-r1.ebuild | 125 +++++++-------------- 2 files changed, 52 insertions(+), 84 deletions(-) (In reply to Paul Fertser from comment #8) > (In reply to jannis from comment #7) > > Since I currently don't have any hardware to test on, would you be able to > > do some basic tests once the ebuild is ready? > > I hope so. Hi Paul, thanks for adding the capstone-configure-switch. I've created an ebuild for v0.11.0-rc1 and created this PR for it: https://github.com/gentoo/gentoo/pull/18899. It would be great if you could test the ebuild and add a comment to the PR that you did so. Thank you! |
This is an auto-filled bug because dev-embedded/openocd fails to compile with -fno-common or gcc-10. The issue was originally discovered on amd64, but it may be reproducible on other arches as well. If you think that a different summary clarifies the issue better, feel free to change it. Attached build log and emerge --info. NOTE: To reproduce this issue you may want to set CFLAGS="${CFLAGS} -fno-common" or compile it with gcc-10 that enables -fno-common by default.