|
From: Ian M. <im...@gm...> - 2005-03-21 05:30:36
|
The other problem with not linking va_copy has been resolved by changing to __va_copy in skas/uaccess.c. This seems to be a known problem with older compilers and there is a patch out there but not in 2.6.11 or by the looks of it 2.6.12 rc1 by my reading of the log (nor for one for my previous e-mail) On Mon, 21 Mar 2005 16:43:54 +1200, Ian McDonald <im...@gm...> wrote: > OK after much further investigation, redownloading of source > (2.6.11.4) and looking at what you have said I know why it is > breaking.... > > I had assumed (wrongly of course) that ARCH_SYSCALLS was a one line > symbol definition but it is much more than this. > > The problem occurs because in both > arch/um/include/sysdep-i386/syscalls.h and in > arch/um/kernel/sys_call_table.c a number of the elements are defined > in BOTH files. > > I presume the reason why this doesn't break others systems is that > they are not using the same version of gcc as me (2.95.4). I would > guess that with a later gcc in an enum you can redefine an element and > it doesn't complain... > > Anyway I believe the proper fix is to delete the lines from > arch/um/kernel/sys_call_table.c and here is a patch to do that: > > 255d254 > < [ __NR_statfs64 ] = (syscall_handler_t *) sys_statfs64, > 258,260d256 > < [ __NR_utimes ] = (syscall_handler_t *) sys_utimes, > < [ __NR_fadvise64_64 ] = (syscall_handler_t *) sys_fadvise64_64, > < [ __NR_vserver ] = (syscall_handler_t *) sys_vserver, > > Can somebody verify that and if correct submit to whoever (this is my > first ever attempt at fixing something in the kernel so not quite sure > what to do next!!) > > Regards, > > Ian > > PS still have some linking issues and I will report on them as I work > out why.... > > On Fri, 18 Mar 2005 18:43:05 -0500, Rob Landley <ro...@la...> wrote: > > Ah, nevermind. Check out Anton's message. You were using a -bk snapshot > > rather than the officially 2.6.11 release, I take it? > > > > Rob > > > |