| Summary: | dev-libs/elfutils: fails to compile on musl: TEMP_FAILURE_RETRY undefined | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Michael Jones <gentoo> |
| Component: | Current packages | Assignee: | Gentoo musl team <musl> |
| Status: | RESOLVED UPSTREAM | ||
| Severity: | normal | CC: | cyborgyn, sam, toolchain |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| URL: | https://sourceware.org/PR21002 | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | |||
| Bug Blocks: | 430702 | ||
| Attachments: | build.log.gz | ||
|
Description
Michael Jones
2016-12-09 09:37:12 UTC
musl guys prob need to debate w/upstream musl and/or elfutils wrt this macro TEMP_FAILURE_RETRY is the tip of the iceberg. elfutils also uses the following by musl unsupported interfaces: - <error.h> - argp - obstacks - fts There is a patched ebuild in: https://github.com/lluixhi/musl-extras/tree/master/dev-libs/elfutils it seems like 0.176 (in the overlay) works, should that be moved over to the tree (updated with the patch r1 adds to the tree), stabilized in the overlay or what (and if stabilized in the overlay, add it to unmask for the overlay)? #(In reply to Matthew Thode ( prometheanfire ) from comment #3) > it seems like 0.176 (in the overlay) works, should that be moved over to the > tree (updated with the patch r1 adds to the tree), stabilized in the overlay > or what (and if stabilized in the overlay, add it to unmask for the overlay)? https://gitweb.gentoo.org/proj/musl.git/tree/dev-libs/elfutils/elfutils-0.176.ebuild for reference. Probably should be stabilised and unmasked, yes. I suggest working with upstream to push patches. It looks like there was some unfinished movement there:
- https://sourceware.org/PR21002
- https://sourceware.org/PR21008
- https://sourceware.org/PR21010
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=92db444e22b25bae835d273dc4e93d0d3534a0be commit 92db444e22b25bae835d273dc4e93d0d3534a0be Author: Sergei Trofimovich <slyfox@gentoo.org> AuthorDate: 2020-03-21 10:32:04 +0000 Commit: Sergei Trofimovich <slyfox@gentoo.org> CommitDate: 2020-03-21 10:37:18 +0000 profiles/features/musl/package.mask: mask dev-libs/elfutils I'm specifically masking elfutils because it's a widespread dependency that pops up all the time when I try to build ::gentoo packages against musl profiles. In ::gentoo dev-libs/elfutils needs an upstream port to musl: #602126, #701478 - https://sourceware.org/PR21002 - https://sourceware.org/PR21008 - https://sourceware.org/PR21010 Overlays that carry out-of-tree patches can remove the mask via `profiles/package.mask`: ``` # unmask in ::${overlay} -dev-libs/elfutils ``` Bug: https://bugs.gentoo.org/602126 Closes: https://bugs.gentoo.org/701478 Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org> profiles/features/musl/package.mask | 8 ++++++++ 1 file changed, 8 insertions(+) The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=d465289bebb01cb8b90344996e9c4e0cd82b93eb commit d465289bebb01cb8b90344996e9c4e0cd82b93eb Author: Sam James <sam@gentoo.org> AuthorDate: 2021-11-07 06:42:40 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2021-11-07 06:44:09 +0000 dev-libs/elfutils: add musl support - Pull in patches and dependencies on libbsd and *-standalone from ::musl - Borrowed a patch or two from upstream elfutils (new release coming shortly) as well as Alpine Linux. Bug: https://bugs.gentoo.org/602126 Bug: https://bugs.gentoo.org/701478 Signed-off-by: Sam James <sam@gentoo.org> dev-libs/elfutils/elfutils-0.185.ebuild | 10 +++ .../elfutils/files/musl/elfutils-0.185-cdefs.patch | 20 ++++++ .../files/musl/elfutils-0.185-error-h.patch | 83 +++++++++++++++++++++ .../files/musl/elfutils-0.185-macros.patch | 84 ++++++++++++++++++++++ .../files/musl/elfutils-0.185-strndupa.patch | 20 ++++++ profiles/features/musl/package.mask | 8 --- 6 files changed, 217 insertions(+), 8 deletions(-) Shouldn't be an issue anymore in tree or upstream in the next release. (In reply to Sam James from comment #8) > Shouldn't be an issue anymore in tree or upstream in the next release. Hi, in the profile "default/linux/musl" they are still there in package.mask for - virtual/libelf - dev-libs/elfutils Which became a show stopper for migrating from libelf to elfutils... (In reply to Barnabás Virágh from comment #9) > (In reply to Sam James from comment #8) > > Shouldn't be an issue anymore in tree or upstream in the next release. > > Hi, in the profile "default/linux/musl" they are still there in package.mask > for > - virtual/libelf > - dev-libs/elfutils > Which became a show stopper for migrating from libelf to elfutils... Hi, 1. We dropped default/linux/musl a few days ago after a looooooooooong period if deprecation (it was only for mips profiles and we've created replacements). features/musl is the base musl one now. 2. I unmasked it almost a year ago in d465289bebb01cb8b90344996e9c4e0cd82b93eb for profiles/features/musl/package.mask. (In reply to Sam James from comment #10) > (In reply to Barnabás Virágh from comment #9) > > (In reply to Sam James from comment #8) > > > Shouldn't be an issue anymore in tree or upstream in the next release. > > > > Hi, in the profile "default/linux/musl" they are still there in package.mask > > for > > - virtual/libelf > > - dev-libs/elfutils > > Which became a show stopper for migrating from libelf to elfutils... > > Hi, > > 1. We dropped default/linux/musl a few days ago after a looooooooooong > period if deprecation (it was only for mips profiles and we've created > replacements). features/musl is the base musl one now. > > 2. I unmasked it almost a year ago in > d465289bebb01cb8b90344996e9c4e0cd82b93eb for > profiles/features/musl/package.mask. My bad! Thought that 3 days old portage sync is fresh enough :D Thank you! No worries, glad it's ok! Let me know if any trouble. I really want musl to work well. |
