Among other things, using -traditional as a gcc option stops us from
using macro token pasting, which is a feature we heavily rely on.
There was still a use of -traditional in arch/x86/kernel/Makefile_64,
which this patch removes.
I don't see any problems building kernels in my x86_64 box without
-traditional.
Signed-off-by: Glauber de Oliveira Costa <[email protected]>
---
arch/x86/kernel/Makefile_64 | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/arch/x86/kernel/Makefile_64 b/arch/x86/kernel/Makefile_64
index 82da906..03a01f6 100644
--- a/arch/x86/kernel/Makefile_64
+++ b/arch/x86/kernel/Makefile_64
@@ -3,7 +3,6 @@
#
extra-y := head_64.o head64.o init_task.o vmlinux.lds
-#EXTRA_AFLAGS := -traditional
obj-y := process_64.o signal_64.o entry_64.o traps_64.o irq_64.o \
ptrace_64.o time_64.o ioport_64.o ldt_64.o setup_64.o i8259_64.o sys_x86_64.o \
x8664_ksyms_64.o i387_64.o syscall_64.o vsyscall_64.o \
--
1.4.4.2
Ok, ok... this was stupid.
I sent the patch against an already-commented out version, which is
the one I was using for testing. Really stupid.
On 10/25/07, Glauber de Oliveira Costa <[email protected]> wrote:
> Among other things, using -traditional as a gcc option stops us from
> using macro token pasting, which is a feature we heavily rely on.
>
> There was still a use of -traditional in arch/x86/kernel/Makefile_64,
> which this patch removes.
>
> I don't see any problems building kernels in my x86_64 box without
> -traditional.
>
> Signed-off-by: Glauber de Oliveira Costa <[email protected]>
> ---
> arch/x86/kernel/Makefile_64 | 1 -
> 1 files changed, 0 insertions(+), 1 deletions(-)
>
> diff --git a/arch/x86/kernel/Makefile_64 b/arch/x86/kernel/Makefile_64
> index 82da906..03a01f6 100644
> --- a/arch/x86/kernel/Makefile_64
> +++ b/arch/x86/kernel/Makefile_64
> @@ -3,7 +3,6 @@
> #
>
> extra-y := head_64.o head64.o init_task.o vmlinux.lds
> -#EXTRA_AFLAGS := -traditional
> obj-y := process_64.o signal_64.o entry_64.o traps_64.o irq_64.o \
> ptrace_64.o time_64.o ioport_64.o ldt_64.o setup_64.o i8259_64.o sys_x86_64.o \
> x8664_ksyms_64.o i387_64.o syscall_64.o vsyscall_64.o \
> --
> 1.4.4.2
>
>
--
Glauber de Oliveira Costa.
"Free as in Freedom"
http://glommer.net
"The less confident you are, the more serious you have to act."
Glauber de Oliveira Costa wrote:
> Among other things, using -traditional as a gcc option stops us from
> using macro token pasting, which is a feature we heavily rely on.
>
> There was still a use of -traditional in arch/x86/kernel/Makefile_64,
> which this patch removes.
>
> I don't see any problems building kernels in my x86_64 box without
> -traditional.
>
> Signed-off-by: Glauber de Oliveira Costa <[email protected]>
> ---
> arch/x86/kernel/Makefile_64 | 1 -
> 1 files changed, 0 insertions(+), 1 deletions(-)
>
> diff --git a/arch/x86/kernel/Makefile_64 b/arch/x86/kernel/Makefile_64
> index 82da906..03a01f6 100644
> --- a/arch/x86/kernel/Makefile_64
> +++ b/arch/x86/kernel/Makefile_64
> @@ -3,7 +3,6 @@
> #
>
> extra-y := head_64.o head64.o init_task.o vmlinux.lds
> -#EXTRA_AFLAGS := -traditional
> obj-y := process_64.o signal_64.o entry_64.o traps_64.o irq_64.o \
> ptrace_64.o time_64.o ioport_64.o ldt_64.o setup_64.o i8259_64.o sys_x86_64.o \
> x8664_ksyms_64.o i387_64.o syscall_64.o vsyscall_64.o \
At least *at one point*, ld scripts were whitespace-sensitive in a way
that called for using -traditional. Doesn't mean that anything else
needs it, though.
-hpa
On Thu, Oct 25, 2007 at 09:47:52AM -0300, Glauber de Oliveira Costa wrote:
> Among other things, using -traditional as a gcc option stops us from
> using macro token pasting, which is a feature we heavily rely on.
>
> There was still a use of -traditional in arch/x86/kernel/Makefile_64,
> which this patch removes.
>
> I don't see any problems building kernels in my x86_64 box without
> -traditional.
>...
Does it also work with gcc 3.2 ?
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
Adrian Bunk wrote:
> On Thu, Oct 25, 2007 at 09:47:52AM -0300, Glauber de Oliveira Costa wrote:
>> Among other things, using -traditional as a gcc option stops us from
>> using macro token pasting, which is a feature we heavily rely on.
>>
>> There was still a use of -traditional in arch/x86/kernel/Makefile_64,
>> which this patch removes.
>>
>> I don't see any problems building kernels in my x86_64 box without
>> -traditional.
>> ...
>
> Does it also work with gcc 3.2 ?
>
It wouldn't be a gcc version issue, it would be a binutils (ld) version
issue.
-hpa
On Thu, Oct 25, 2007 at 10:56:58AM -0700, H. Peter Anvin wrote:
> Adrian Bunk wrote:
>> On Thu, Oct 25, 2007 at 09:47:52AM -0300, Glauber de Oliveira Costa wrote:
>>> Among other things, using -traditional as a gcc option stops us from
>>> using macro token pasting, which is a feature we heavily rely on.
>>>
>>> There was still a use of -traditional in arch/x86/kernel/Makefile_64,
>>> which this patch removes.
>>>
>>> I don't see any problems building kernels in my x86_64 box without
>>> -traditional.
>>> ...
>> Does it also work with gcc 3.2 ?
>
> It wouldn't be a gcc version issue, it would be a binutils (ld) version
> issue.
Sorry for the dumb question, but how does or did the gcc -traditional
option affect ld?
> -hpa
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
Adrian Bunk wrote:
> Sorry for the dumb question, but how does or did the gcc -traditional
> option affect ld?
>
vmlinux.lds is run through cpp (as a .S file).
J
On 10/25/07, Jeremy Fitzhardinge <[email protected]> wrote:
> Adrian Bunk wrote:
> > Sorry for the dumb question, but how does or did the gcc -traditional
> > option affect ld?
> >
>
After a while, there is no issue I can find on x86_64 by taking out
the -traditional flag. Everything seems fine.
--
Glauber de Oliveira Costa.
"Free as in Freedom"
http://glommer.net
"The less confident you are, the more serious you have to act."