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.
Created attachment 410924 [details] emerge.info
This is related to the new C locale of musl-1.11. There is a thread http://www.openwall.com/lists/musl/2015/09/01/3 on the musl list. So downgrading to musl-1.10 should also be a workaround.
(In reply to Felix Janda from comment #2) > This is related to the new C locale of musl-1.11. There is a thread > > http://www.openwall.com/lists/musl/2015/09/01/3 > > 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?
Created attachment 410954 [details, diff] Patch for musl (untested)
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?
@ felix I guess your patch does break quite a few things, causing file collisions to be more precise. have a look here https://bugs.gentoo.org/show_bug.cgi?id=545502#c5 should we open a new bug about the regression and close this one to make things less confusing?
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?
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?
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.
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.
Alpine Linux uses now the same patch: http://git.alpinelinux.org/cgit/aports/commit/?id=3e4dc327b193eb85e43c466be9f13d3a82101f1a
And an equivalent patch has been committed to musl git master: http://git.musl-libc.org/cgit/musl/commit/?id=844212d94f582c4e3c5055e0a1524931e89ebe76
fixed with musl-1.1.12
