Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!

Bug 559520

Summary: =x11-proto/xcb-proto-1.11 fails to build on musl with python3_4 bindings
Product: Gentoo Linux Reporter: tt_1 <herrtimson>
Component: [OLD] UnspecifiedAssignee: Gentoo musl team <musl>
Severity: normal CC: blueness
Priority: Normal    
Version: unspecified   
Hardware: All   
OS: Linux   
Package list:
Runtime testing required: ---
Bug Depends on:    
Bug Blocks: 430702, 546890    
Attachments: config-error.log from autoconf
Patch for musl (untested)

Description tt_1 2015-09-03 12:40:37 UTC
Created attachment 410922 [details]
config-error.log from autoconf

a workaround is to put this into you package.use 

=x11-proto/xcb-proto-1.11::gentoo -python_targets_python3_4 

it seems to be a musl exclusive problem, as I am able to compile the python3_4 bindings on my regular machine without any problems.
Comment 1 tt_1 2015-09-03 12:41:53 UTC
Created attachment 410924 [details]
Comment 2 Felix Janda 2015-09-03 18:15:58 UTC
This is related to the new C locale of musl-1.11. There is a thread

on the musl list.

So downgrading to musl-1.10 should also be a workaround.
Comment 3 Anthony Basile gentoo-dev 2015-09-03 20:32:35 UTC
(In reply to Felix Janda from comment #2)
> This is related to the new C locale of musl-1.11. There is a thread
> on the musl list.
> So downgrading to musl-1.10 should also be a workaround.

Darn, a regression.  Can we isolate a patch against 1.11 and I'll push out -r1?
Comment 4 Felix Janda 2015-09-03 21:03:43 UTC
Created attachment 410954 [details, diff]
Patch for musl (untested)
Comment 5 tt_1 2015-09-03 21:52:44 UTC
I could test the patch tomorrow for this specific case and for @system. By the way, why is musl not included in the @system template? 

Could you explain the patch a bit for the non professional?
Comment 6 tt_1 2015-09-04 07:31:29 UTC
@ felix 

I guess your patch does break quite a few things, causing file collisions to be more precise. have a look here

should we open a new bug about the regression and close this one to make things less confusing?
Comment 7 Felix Janda 2015-09-04 17:37:35 UTC
The patch tries to implement the suggestion of Rich Felker: Make
nl_langinfo(CODESET) always return "UTF-8".

@ tt_1:
I can reproduce (in the example of sys-apps/sed) the installation of
charset.alias despite the INSTALL_MASK in make.defaults. However it
seems to happen no matter whether the patch against musl is applied or
not. Are you sure that during your tests you have changed nothing other
than whether to patch musl?
Comment 8 tt_1 2015-09-05 13:13:51 UTC
I cannot reproduce the file collisions on a clean stage 3. Neither with the utf-8 patch for musl being applied, nor the 213-posix_memalign.patch for gcc-4.8.5. The results of emerge --info I attached in this bug are from the suspicious chroot where I cannot reproduce the file collision.  

@ Felix: 

what about you?
Comment 9 Felix Janda 2015-09-05 15:10:27 UTC
I've found the cause for the INSTALL_MASK issue:

If you use INSTALL_MASK="..." in make.conf, it will override the
INSTALL_MASK from the profile. With INSTALL_MASK="${INSTALL_MASK} ..."
it is still honored.
Comment 10 tt_1 2015-09-05 15:51:56 UTC
correct - I had #INSTALL_MASK="locale.alias" in my make.conf due to #545502. 

with INSTALL_MASK="${INSTALL_MASK} locale.alias" , no more file collisions.
Comment 11 Felix Janda 2015-09-07 17:44:53 UTC
Alpine Linux uses now the same patch:
Comment 12 Felix Janda 2015-09-09 18:20:40 UTC
And an equivalent patch has been committed to musl git master:
Comment 13 tt_1 2015-10-25 14:42:33 UTC
fixed with musl-1.1.12