Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 529380 - dev-libs/pth-2.0.7-r3: fix compilation on musl branch
Summary: dev-libs/pth-2.0.7-r3: fix compilation on musl branch
Status: RESOLVED WONTFIX
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Library (show other bugs)
Hardware: All Linux
: Normal normal
Assignee: Crypto team [DISABLED]
URL:
Whiteboard: hardened-devel repo, musl overlay
Keywords: PATCH
Depends on:
Blocks:
 
Reported: 2014-11-15 20:29 UTC by DaggyStyle
Modified: 2014-11-18 21:25 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
patch (pth-2.0.7-musl-fix.patch,948 bytes, patch)
2014-11-15 20:29 UTC, DaggyStyle
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description DaggyStyle 2014-11-15 20:29:01 UTC
this patch allow sys-boot/grub-2.02_beta2-r2 to compile and run under gentoo over musl

Reproducible: Always
Comment 1 DaggyStyle 2014-11-15 20:29:31 UTC
Created attachment 389446 [details, diff]
patch
Comment 2 DaggyStyle 2014-11-15 20:30:28 UTC
this patch allow dev-libs/pth-2.0.7-r3 to compile and run under gentoo over musl

bad copy paste, my bad, trying to keep the format identical
Comment 3 Alon Bar-Lev (RETIRED) gentoo-dev 2014-11-17 12:40:36 UTC
you enable a code that was conditional and probably damage other sequences.

please discuss with upstream what should be added, also please notice that pth is no longer used in gnupg-2.1
Comment 4 DaggyStyle 2014-11-17 18:15:45 UTC
(In reply to Alon Bar-Lev from comment #3)
> you enable a code that was conditional and probably damage other sequences.
> 

musl upstream or pth upstream?

> please discuss with upstream what should be added, also please notice that
> pth is no longer used in gnupg-2.1

no sure I understand what gnupg has to do with this bug.
Comment 5 Alon Bar-Lev (RETIRED) gentoo-dev 2014-11-18 10:15:44 UTC
(In reply to DaggyStyle from comment #4)
> (In reply to Alon Bar-Lev from comment #3)
> > you enable a code that was conditional and probably damage other sequences.
> > 
> 
> musl upstream or pth upstream?
> 

pth upstream... although they will accept no patches.

> > please discuss with upstream what should be added, also please notice that
> > pth is no longer used in gnupg-2.1
> 
> no sure I understand what gnupg has to do with this bug.

gnupg is the only consumer of this old package as far as I understand.

anyway, you should add conditional and not remove conditional when you are porting to another environment.
Comment 6 DaggyStyle 2014-11-18 19:19:34 UTC
(In reply to Alon Bar-Lev from comment #5)
> (In reply to DaggyStyle from comment #4)
> > (In reply to Alon Bar-Lev from comment #3)
> > > you enable a code that was conditional and probably damage other sequences.
> > > 
> > 
> > musl upstream or pth upstream?
> > 
> 
> pth upstream... although they will accept no patches.
> 
will try.

> > > please discuss with upstream what should be added, also please notice that
> > > pth is no longer used in gnupg-2.1
> > 
> > no sure I understand what gnupg has to do with this bug.
> 
> gnupg is the only consumer of this old package as far as I understand.
> 
> anyway, you should add conditional and not remove conditional when you are
> porting to another environment.

I'm trying to work wit what's stable, that is why gnupg polls it in.
technically I didn't removed a condition, the issue is that there is no way codewise to know one is compiling against musl
Comment 7 Alon Bar-Lev (RETIRED) gentoo-dev 2014-11-18 19:21:29 UTC
(In reply to DaggyStyle from comment #6)
> > anyway, you should add conditional and not remove conditional when you are
> > porting to another environment.
> 
> I'm trying to work wit what's stable, that is why gnupg polls it in.
> technically I didn't removed a condition, the issue is that there is no way
> codewise to know one is compiling against musl

you did remove conditional.
if there is no way to detect musl, please contact upstream so they add such to enable use of conditionals.
Comment 8 DaggyStyle 2014-11-18 21:17:24 UTC
(In reply to Alon Bar-Lev from comment #7)
> (In reply to DaggyStyle from comment #6)
> > > anyway, you should add conditional and not remove conditional when you are
> > > porting to another environment.
> > 
> > I'm trying to work wit what's stable, that is why gnupg polls it in.
> > technically I didn't removed a condition, the issue is that there is no way
> > codewise to know one is compiling against musl
> 
> you did remove conditional.
> if there is no way to detect musl, please contact upstream so they add such
> to enable use of conditionals.
it won't be added, see http://openwall.com/lists/musl/2013/03/29/13.

I will however try to ask again if there is a way to know that.
Comment 9 Alon Bar-Lev (RETIRED) gentoo-dev 2014-11-18 21:25:34 UTC
(In reply to DaggyStyle from comment #8)
> (In reply to Alon Bar-Lev from comment #7)
> > (In reply to DaggyStyle from comment #6)
> > > > anyway, you should add conditional and not remove conditional when you are
> > > > porting to another environment.
> > > 
> > > I'm trying to work wit what's stable, that is why gnupg polls it in.
> > > technically I didn't removed a condition, the issue is that there is no way
> > > codewise to know one is compiling against musl
> > 
> > you did remove conditional.
> > if there is no way to detect musl, please contact upstream so they add such
> > to enable use of conditionals.
> it won't be added, see http://openwall.com/lists/musl/2013/03/29/13.
> 
> I will however try to ask again if there is a way to know that.

so please find a solution to test what you need and define proper conditionals.

in any case disabling conditional to damage the environments other than glibc is incorrect.

I am closing this, please reopen when you have valid musl specific solution that does not effect any other implementation.

Preferably upstream accepts solution.