| Summary: | dev-libs/pth-2.0.7-r3 doesn't compile on musl | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Philipp Ammann <philipp.ammann> |
| Component: | [OLD] Unspecified | Assignee: | Gentoo musl team <musl> |
| Status: | RESOLVED OBSOLETE | ||
| Severity: | normal | CC: | alonbl, blueness, embedded, gentoo, hardened, herrtimson |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | |||
| Bug Blocks: | 430702 | ||
|
Description
Philipp Ammann
2014-10-12 11:52:06 UTC
(In reply to Philipp Ammann from comment #0) > GNU PTH doesn't compile on musl due to some glibc-isms: > > pth_mctx.c: In function ‘__pth_mctx_set’: > pth_mctx.c:480:2: error: #error "Unsupported Linux (g)libc version and/or > platform" > > In pth_mctx.c, they offer multiple variants to do the machine state > switching. I manually edited the IFDEFs to try the various versions, but to > no avail. According to the comments, variant 2 should run "really on _all_ > POSIX compliant systems" but doesn't. > > Sorry I can't offer a patch, but since I'm no programmer, editing the IFDEFs > is really all I can do. > Yes, this is a known issue. pth is basically "portable" (heh!) threads which is pretty much dead. We do have a hacky fix, but its the wrong approach because pth insists on looking at implementation details which it should not. I'm guessing you hit this because of gnupg-2. If so, for now use gnupg-1. there is a version of gnupg-2 which uses pth-ng which does work. You can test that now if you like, or just wait until its stabilized. > I'm guessing you hit this because of gnupg-2. If so, for now use gnupg-1.
> there is a version of gnupg-2 which uses pth-ng which does work. You can
> test that now if you like, or just wait until its stabilized.
Yes, it's because of gnupg. The 2.1 beta (which relies on npth) doesn't compile, I'll have to look into that. And the ebuild pulls in a lot of hard dependencies (openldap and gnutls, among others), which - after a quick look at ./configure --help - may not be necessary. I'll notify you if I get it to work.
In the meantime, do you know if there's a patch for 2.0 to use npth?
(In reply to Philipp Ammann from comment #2) > > I'm guessing you hit this because of gnupg-2. If so, for now use gnupg-1. > > there is a version of gnupg-2 which uses pth-ng which does work. You can > > test that now if you like, or just wait until its stabilized. > > Yes, it's because of gnupg. The 2.1 beta (which relies on npth) doesn't > compile, I'll have to look into that. And the ebuild pulls in a lot of hard > dependencies (openldap and gnutls, among others), which - after a quick look > at ./configure --help - may not be necessary. I'll notify you if I get it to > work. > > In the meantime, do you know if there's a patch for 2.0 to use npth? No sorry, no patch for 2.0 + npth. Does npth at least compile on musl, let's start there. We could open a bug for 2.1 beta independantly of musl. I don't see why it should hard depend on openldap. The gnutls dependency is probably unavoidable. And I assume the other dependencies are secondary to openldap and gnutls. (In reply to Anthony Basile from comment #3) > No sorry, no patch for 2.0 + npth. Does npth at least compile on musl, > let's start there. Yes npth-1.0 does compile on musl. > We could open a bug for 2.1 beta independantly of musl. I don't see why it > should hard depend on openldap. The gnutls dependency is probably > unavoidable. And I assume the other dependencies are secondary to openldap > and gnutls. See bug #525154 is it possible to mask dev-libs/pth for the musl profile? (In reply to tt_1 from comment #5) > is it possible to mask dev-libs/pth for the musl profile? yep, done! gnupg-2.1 uses npth And so I think >=gnupg-2.1 should be stabilized for arm to really resolve this bug. musl is not stable blocker as far as I know |
