From: Matthew R. S. <use...@go...> - 2003-09-16 18:29:49
|
With both of these patches I am getting the following error during compile: gcc-2.95 -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -march=pentium -O3 -pipe -fomit-frame-pointer -U__i386__ -Ui386 -DUM_FASTCALL -g -D__arch_um__ -DSUBARCH=\"i386\" -D_LARGEFILE64_SOURCE -I/ home/gldnspud/uml/build/buildkernel-build/linux/arch/um/include -I/home/ gldnspud/uml/build/buildkernel-build/linux/arch/um/kernel/tt/include -I/home/ gldnspud/uml/build/buildkernel-build/linux/arch/um/kernel/skas/include -D_GNU_SOURCE -c -o umid.o umid.c In file included from umid.c:18: /home/gldnspud/uml/build/buildkernel-build/linux/arch/um/include/os.h:41: warning: no semicolon at end of struct or union /home/gldnspud/uml/build/buildkernel-build/linux/arch/um/include/os.h:41: parse error before `.' /home/gldnspud/uml/build/buildkernel-build/linux/arch/um/include/os.h:42: parse error before `.' /home/gldnspud/uml/build/buildkernel-build/linux/arch/um/include/os.h:43: parse error before `.' make[4]: *** [umid.o] Error 1 make[4]: Leaving directory `/home/gldnspud/uml/build/buildkernel-build/linux/ arch/um/kernel' make[3]: *** [first_rule] Error 2 make[3]: Leaving directory `/home/gldnspud/uml/build/buildkernel-build/linux/ arch/um/kernel' make[2]: *** [_dir_arch/um/kernel] Error 2 make[2]: Leaving directory `/home/gldnspud/uml/build/buildkernel-build/linux' make[1]: *** [buildkernel-build-stamp] Error 2 make[1]: Leaving directory `/home/gldnspud/uml/build' make: *** [build-stamp] Error 2 When I look at line 41, 42, and 43 in arch/um/include/os.h though, there doesn't seem to be any sort of problems. Those lines are in the middle of a perfectly valid-looking struct. -- Matthew R. Scott OMAjA / http://www.omaja.com/ |
From: BlaisorBlade <bla...@ya...> - 2003-09-17 18:14:25
|
Alle 20:29, marted=EC 16 settembre 2003, Matthew R. Scott ha scritto: > With both of these patches I am getting the following error during compil= e: I use the headers from glibc-devel-2.3.1-10mdk(from mandrake 9.1) and I get= =20 the same errors. Supposed that the patch compiles well somewhere else, it's= =20 something changed with glibc from the system of who released the patch. See= =20 below, especially where the code snippets speak about backward compatibilit= y. > In file included from umid.c:18: > /home/gldnspud/uml/build/buildkernel-build/linux/arch/um/include/os.h:41: > warning: no semicolon at end of struct or union > /home/gldnspud/uml/build/buildkernel-build/linux/arch/um/include/os.h:41: > parse error before `.' > /home/gldnspud/uml/build/buildkernel-build/linux/arch/um/include/os.h:42: > parse error before `.' > /home/gldnspud/uml/build/buildkernel-build/linux/arch/um/include/os.h:43: > parse error before `.' > > When I look at line 41, 42, and 43 in arch/um/include/os.h though, there > doesn't seem to be any sort of problems. Those lines are in the middle of > a perfectly valid-looking struct. I agree, but cd to that folder and rerun the exact gcc command, replacing -= c=20 =2Do umid.o with -E(to preprocess only the file), then use less(the=20 preprocessed output is sent to stdout). On about line 5295(on me, look well= ),=20 you can see that those line, because of a preprocessor #define, get turned= =20 into something else. The os.h file is good, but in umid.c it's included aft= er=20 sys/stat.h(which is the glibc one!). It then includes in turn bits/stat.h: #ifdef __USE_MISC =09 # define st_atime st_atim.tv_sec /* Backward compatibility. */ # define st_mtime st_mtim.tv_sec # define st_ctime st_ctim.tv_sec =2E.. __USE_MISC comes from features.h; if you define __BSD_SOURCE(to choose this= =20 dialect of Unix) it gets defined; if you don't define anything, it comes up= =20 automatically. Anyway we need it in the code below. I've given this command inside arch/um to find what includes both os.h and= =20 sys/stat.h # grep 'os\.h\"' $(grep 'sys/stat\.h' `find . -name '*.[ch]'` -l) =2E/drivers/chan_user.c:#include "os.h" =2E/os-Linux/file.c:#include "os.h" =2E/kernel/umid.c:#include "os.h" =2E/kernel/initrd_user.c:#include "os.h" I've tried #undefining them, but they are needed somewhere else(in file.c),= so=20 I've simply swapped the order of the two includes(so that os.h is included= =20 with those define's not in place). And yet, it doesn't compile. It stops on= =20 file.c. This is the offending code(which was absent from the cleanup of -4um): static void copy_stat(struct uml_stat* dst, struct stat64* src) { *dst=3D((struct uml_stat) { .st_dev =3D src->st_dev, /* device */ .st_ino =3D src->st_ino, /* inode */ .st_mode =3D src->st_mode, /* protection */ .st_nlink =3D src->st_nlink, /* number of hard links */ .st_uid =3D src->st_uid, /* user ID of owner */ .st_gid =3D src->st_gid, /* group ID of owner */ .st_size =3D src->st_size, /* total size, in bytes */ .st_blksize =3D src->st_blksize, /* blocksize for filesys I= /O */ .st_blocks =3D src->st_blocks, /* number of blocks alloca= ted=20 */ .st_atime =3D src->st_atime, /* time of last access */ .st_mtime =3D src->st_mtime, /* time of last modificati= on */ .st_ctime =3D src->st_ctime, /* time of last change */ }); } As you can see, on the same line it needs that st_{a,m,c}time is its litera= l=20 value on the right and the original vaue on the left. I am available to=20 anyone who wants to fix the bug with help, actual hacking and whatever, but= =20 I'm not starting because I don't know how... if I #undef the things, then I= =20 need to patch the above function to use directly st_atim.tv_sec, and then=20 maybe things won't work on systems where they worked before. =2D-=20 cat <<EOSIGN Paolo Giarrusso, aka Blaisorblade Linux Kernel 2.4.21/2.6.0-test on an i686; Linux registered user n. 292729 EOSIGN |
From: Jeff D. <jd...@ad...> - 2003-09-17 22:19:52
|
bla...@ya... said: > # define st_atime st_atim.tv_sec /* Backward compatibility. */ ... > .st_atime = src->st_atime, /* time of last access */ This is just because of the names of the struct uml_stat. Changing those field names should fix the compile problem. Jeff |
From: Jeff D. <jd...@ad...> - 2003-11-10 01:15:33
|
use...@go... said: > When I look at line 41, 42, and 43 in arch/um/include/os.h though, > there doesn't seem to be any sort of problems. Those lines are in > the middle of a perfectly valid-looking struct. This should be fixed now. The problem was that those field names were #defined in a header to be something else. Jeff |