I started getting following linking error on amd64 after the 2.6.25
patch floodgates were opened:
[snip]
  CHK     include/linux/compile.h
  UPD     include/linux/compile.h
  CC      init/version.o
  LD      init/built-in.o
  LD      .tmp_vmlinux1
arch/x86/vdso/built-in.o: In function `init_vdso_vars':
vma.c:(.init.text+0x170): undefined reference to `VDSO64_vgetcpu_mode'
vma.c:(.init.text+0x1a3): undefined reference to `VDSO64_vsyscall_gtod_data'
vma.c:(.init.text+0x1aa): undefined reference to `VDSO64_vgetcpu_mode'
vma.c:(.init.text+0x1d8): undefined reference to `VDSO64_vsyscall_gtod_data'
make: *** [.tmp_vmlinux1] Error 1

Bisecting turned up following commit:
2b9c97e16101e8dc2b0810d6f932d475a051d785 is first bad commit
commit 2b9c97e16101e8dc2b0810d6f932d475a051d785
Author: Roland McGrath <roland@redhat.com>
Date:   Wed Jan 30 13:30:41 2008 +0100

    x86 vDSO: remove vdso-syms.o
    
    Get rid of vdso-syms.o from the kernel link.  We don't need it any more.
    
    Signed-off-by: Roland McGrath <roland@redhat.com>
    Cc: Andrew Morton <akpm@linux-foundation.org>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Ingo Molnar <mingo@elte.hu>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>


To test get the error, just disable 32 bit emulation (IA32_EMULATION)

Cheers,
Priit ;)
--

[ message continues ]

I was not able to reproduce this failure.  Those symbols should be defined
by arch/x86/vdso/vdso-syms.lds, a file generated by the build.  If that
file is empty in your build, remove it and see if it gets regenerated
properly, or try a clean build.  If the problem persists, please send me
your complete .config file.


Thanks,
Roland
--

[ message continues ]

if that file is empty, it might be the effect of a Ctrl-C. I sometimes 
get that on .o files, if i Ctrl-C a highly parallel make -j at the wrong 
moment. (is this expected behavior? It's been like this for a long 
time.)

	Ingo
--

[ message continues ]

It is the known situation with the compiler since the dawn of time, yes.
It just writes the file directly, so if it dies in the middle, there's a
file with a fresh date.  For things like this done in makefile commands
with >, it has forever been canonical for the anal to use:

	... > $@.new
	mv -f $@.new $@

which avoids the problem.  The kernel makefiles are entirely haphazard
about places that do this or don't.  It uglifies the commands, but avoids
the problem of freshly-dated but wrong/empty files from botched make runs.
I did not do this in cmd_vdsosym (though I did in cmd_vdso32sym, go figure).


Thanks,
Roland
--

[ message continues ]

Sam might want to experiment with something like:

	stdout_target = $(1) > $(@D)/.tmp_$(@F) && mv -f $(@D)/.tmp_$(@F) $@

	cmd_foo = $(call stdout_target,blah | sed s/foo/bar/)

to clean up all the places that would benefit from robust treatment for
output files vs interrupted/erring make runs.


Thanks,
Roland
--

[ message continues ]

In most cases however, issuing ctrl+c signals make and make will
remove the output file.

Problematic indeed, "temp" could be left when ctrl+c is hit:
foo: bar
	generate-something <bar >temp;
	add-up <temp >foo;

What could work, temp being removed on ^C:
temp: bar
	generate-something <bar >temp;
foo: temp
	add-up <temp >foo;
--

[ message continues ]

=C3=9Chel kenal p=C3=A4eval, E, 2008-02-11 kell 14:53, kirjutas Roland McGr=
This fails with clean build. And vdso-syms.lds is not empty.

Contents of =EF=BB=BFarch/x86/vdso/vdso-syms.lds:
VDSO64_PRELINK =3D 0xffffffffff700000;
VDSO64_jiffies =3D 0xffffffffff7004b8;

.config attached or can be viewed at
http://plaes.org/files/2008-Q1/dot_config_VDSO64_error


Hope this helps,
Priit
[ message continues ]

Odd.  The missing symbols come from the same place that VDSO64_jiffies did.
The end of the arch/x86/vdso/vdso.lds file in your build should have these:

VDSO64_jiffies = vdso_jiffies;
VDSO64_vgetcpu_mode = vdso_vgetcpu_mode;
VDSO64_vsyscall_gtod_data = vdso_vsyscall_gtod_data;

readelf -s arch/x86/vdso/vvar.o in your build should show (among others):

     8: 0000000000000000     8 OBJECT  GLOBAL DEFAULT    4 vdso_jiffies
     9: 0000000000000008     8 OBJECT  GLOBAL DEFAULT    4 vdso_vgetcpu_mode
    10: 0000000000000010     8 OBJECT  GLOBAL DEFAULT    4 vdso_vsyscall_gtod_data

If either of those is not all there, you'll have to look into what's
happening in the generation of the respective files.


Thanks,
Roland
--

[ message continues ]