dev-util/kbuild fails to build on amd64

[stefson]

recently I tried to merge =dev-util/kbuild-0.1.9998_pre20131130-r1::musl-extras but it fails due to this error

kBuild-0.1.9998-pre20131130/src/kmk/kmkbuiltin/cp.c:85:14: error: conflicting types for ‘strlcpy’ extern char strlcpy(char , const char *, size_t);

here is the full build.log kbuild-failed-build.log.gz

and my emerge --info emerge.info.gz

[lluixhi]

Hmm. So the issue is that strlcpy is being defined on your machine even though I changed the guard in cp.c from:

#if defined(_MSC_VER) || defined(__gnu_linux__) || defined(__linux__)

to

#if defined(_MSC_VER) || defined(__gnu_linux__) && !defined(__UCLIBC__)

So I have to wonder -- why is gcc-4.9.3-r99 (or gcc-4.9.4-r99) defining __gnu_linux__?

EDIT: Figured it out. gcc-4.9.3/4 in ::musl is still doing the weird hack which instead of building gcc for musl as os/generic, it moves the os/generic code to os/gnu-linux and builds it. So it defines __gnu_linux__. Upstream decided this was the wrong way to do it (especially because this method overwrites using GLIBC), and sys-devel/gcc-5.x and sys-devel/6.x in this repository follow the correct convention (the patches I'm using came from upstream gcc-6.x patches)

I guess I can try and fix the compilers over there -- I'll get to it eventually when I migrate the gcc ebuilds im maintaining -- probably when gcc-6.3.0 hits the tree.

[stefson]

Ah, okay, so the reason is the badly patched gcc 4.9. Are you thinking about patching this one, or are you talking about patching either gcc-5.x or gcc-6?

[lluixhi]

I'm thinking about fixing gcc-4.9.4 so it matches the gcc-6 behaviour.

[lluixhi]

Alright, I just went through reorganizing/cleaning up patches for 4.9.4/5.4.0/6.1.0

Could you test =sys-devel/gcc-4.9.4::musl-extras?

[stefson]

Just grabbed a fresh stage3, merged gcc:4.9.4::musl-extras and kbuild builds just fine! You may want to discuss further details with @blueness?

[blueness]

@lluixhi go ahead an put 6.1.0 on the gentoo/musl overlay as ~arch and i'll test it out for the stages. i need to make sure it works with USE=hardened before i start using it for the stages. this may be the way we transition to the in-tree version of gcc.

[lluixhi]

Well -- it's actually gcc-6.2.0 But anyway, do you care for moving gcc-5.4.0 and replacing the version of gcc-4.9.4 that is currently in the musl overlay or what?

I've actually been using gcc-6.2.0-r1 with pie and ssp enabled for a while now (the hardened use flag appears to have been retired, and both of those flags are hard-masked) The biggest issue for me at the moment is that the linux kernel requires a patch in order to pass -fno-PIE when building.

[blueness]

I know about the kernel patch thingy. I've been meaning to pass a patch upstream but I've been so busy with real life.

[lluixhi]

Correcting myself again, I'd be moving over 6.3.0 @bluness You didn't answer my question -- should I move over 4.9.4 and 5.4.0 from this repository?

[blueness]

@lluixhi if you want to move 5.4.0 okay but not 4.9.4. I'm going to continue using the old patchset with 4.9.x. I will test 6.x wrt building the stage3's and then jump from 4.9.x to 6.x. Whether 5.x is there or not, I don't care.

[lluixhi]

Alright. Done.