2
0
mirror of https://github.com/edk2-porting/linux-next.git synced 2024-12-25 21:54:06 +08:00
Commit Graph

6 Commits

Author SHA1 Message Date
Michal Marek
07105202bd Makefile: do not override LC_CTYPE
Setting LC_CTYPE=C breaks localized messages in some setups. With only
LC_COLLATE=C and LC_NUMERIC=C, we get almost all we need, except for not
so defined character classes and tolower()/toupper(). The former is not
a big issue, because we can assume that e.g. [:alpha:] will always
include a-zA-Z and we only ever process ASCII input. The latter seems
only affect arch/sh/tools/gen-mach-types, which we can handle separately.

So after this patch the meaning of ranges like [a-z], the behavior of
sort and join, etc. should be the same everywhere and at the same time
gcc should be able to print localized waring and error messages.
LC_NUMERIC=C might not be necessary, but setting it doesn't hurt.

Reported-by: Simon Horman <horms@verge.net.au>
Reported-by: Sergei Trofimovich <slyfox@inbox.ru>
Acked-by: H. Peter Anvin <hpa@zytor.com>
Tested-by: Simon Horman <horms@verge.net.au>
Tested-by: Masami Hiramatsu <mhiramat@redhat.com>
Signed-off-by: Michal Marek <mmarek@suse.cz>
2010-01-13 13:27:24 +01:00
Sam Ravnborg
3252b11fc4 sh: move machtypes.h to include/generated
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Cc: Paul Mundt <lethal@linux-sh.org>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Michal Marek <mmarek@suse.cz>
2009-12-12 13:08:14 +01:00
Paul Mundt
4385e12b29 sh: Revert the location change of auto-generated asm/machtypes.h
This ended up causing build breakage on O= builds, as reported by Adrian:

<--  snip  -->

...
  CC      init/main.o
In file included from /home/bunk/linux/kernel-2.6/git/linux-2.6/arch/sh/include/asm/irq.h:4,
                 from /home/bunk/linux/kernel-2.6/git/linux-2.6/include/linux/irq.h:23,
                 from /home/bunk/linux/kernel-2.6/git/linux-2.6/arch/sh/include/asm/hardirq.h:5,
                 from /home/bunk/linux/kernel-2.6/git/linux-2.6/include/linux/hardirq.h:7,
                 from /home/bunk/linux/kernel-2.6/git/linux-2.6/include/asm-generic/local.h:5,
                 from /home/bunk/linux/kernel-2.6/git/linux-2.6/arch/sh/include/asm/local.h:4,
                 from /home/bunk/linux/kernel-2.6/git/linux-2.6/include/linux/module.h:19,
                 from /home/bunk/linux/kernel-2.6/git/linux-2.6/init/main.c:13:
/home/bunk/linux/kernel-2.6/git/linux-2.6/arch/sh/include/asm/machvec.h:15:27:
error: asm/machtypes.h: No such file or directory
make[2]: *** [init/main.o] Error 1

<--  snip  -->

So we simply move machtypes.h back to its original place. asm-offsets.h is
still generated there regardless, until such a time that we find a better place
to stash auto-generated files.

Reported-by: Adrian Bunk <bunk@kernel.org>
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
2008-08-02 07:14:09 +09:00
Paul Mundt
f15cbe6f1a sh: migrate to arch/sh/include/
This follows the sparc changes a439fe51a1.

Most of the moving about was done with Sam's directions at:

http://marc.info/?l=linux-sh&m=121724823706062&w=2

with subsequent hacking and fixups entirely my fault.

Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
2008-07-29 08:09:44 +09:00
Erik Johansson
8cb661d6a4 sh: fix race in parallel out-of-tree build
Depending on which of the three dependencies for archprepare (in
arch/sh/Makefile) get built first, the directory include/asm-sh may or
may not exist when the maketools target is built. If the directory does
not exist, awk will fail to generate machtypes.h. This patch fixes this
by creating the directory before awk is executed.

Signed-off-by: Erik Johansson <erik.johansson@motorola.com>
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
2007-07-12 16:37:00 +09:00
Linus Torvalds
1da177e4c3 Linux-2.6.12-rc2
Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.

Let it rip!
2005-04-16 15:20:36 -07:00