On Tue, Jun 21, 2016 at 02:36:34PM -0400, Chris Metcalf wrote: > On 6/21/2016 2:28 PM, Peter Zijlstra wrote: > >I had to s/__atomic_fetch/__atomic32_fetch/ to avoid a namespace clash > >with the builtin C11 atomic primitives. > > > >You want me to rename them all to regain consistent naming? > > Yes, it's probably the right thing to do. All the internal routines with "atomic32" > or "atomic64" I assume you mean? Yep, after this patch we have a few __atomic_ and a few __atomic32_, which is rather unbecoming. Lemme go convert them all to __atomic32_. > So what's your build process for the cross tools, by the way? I'm assuming > you're not doing a total bootstrap cross-tool build since you'd need minimal > kernel headers (linux/errno.h or whatever) in that case. I assume you're using > the host headers to build the cross tool? > > So I'm a little confused how the other kernel headers are working out for you, > e.g. <arch/icache.h> is referenced when building the tilegx libgcc. I've no idea; I use this thing: git://git.infradead.org/users/segher/buildall.git Although I've got some local modifications, none are to the actual toolchain building part (although I suppose I should send segher a patch). I have binutils-gdb.git and gcc.bit checkouts and point the buildall config to that (both are on latest stable branches binutils-2_26-branch and gcc-6-branch resp.). And I point the kernel path to my current hacked up tree. I don't really rebuild the entire toolchains often, mostly only when I really need a new GCC or its getting really old (like I used 5.3.0 for a long while). -- To unsubscribe from this list: send the line "unsubscribe linux-next" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
