From: Ryan A. <ry...@mi...> - 2005-04-27 03:04:28
|
I've been seeing a build error when trying to build User Mode Linux on an x86-32 host (Athlon, fwiw). The kernel I'm building is a 1-day old pull from git. This error is not new, though. I thought it was merely an artifact of a patch stuck in a queue at first so I didn't mention it right away. ryan@mythryan2 ~/dev/linux/linux-git$ make O=/home/ryan/dev/linux/output/uml ARCH="um" -j4 CC="ccache distcc" clean /bin/bash: line 1: cd: arch/um: No such file or directory ryan@mythryan2 ~/dev/linux/linux-git$ make O=/home/ryan/dev/linux/output/uml ARCH="um" -j4 CC="ccache distcc" oldconfig /bin/bash: line 1: cd: arch/um: No such file or directory HOSTCC scripts/basic/fixdep GEN /home/ryan/dev/linux/output/uml/Makefile HOSTCC scripts/basic/split-include HOSTCC scripts/basic/docproc HOSTCC scripts/kconfig/conf.o HOSTCC scripts/kconfig/mconf.o HOSTCC scripts/kconfig/zconf.tab.o HOSTLD scripts/kconfig/conf scripts/kconfig/conf -o arch/um/Kconfig arch/um/Kconfig:71: can't open file "arch/um/Kconfig_arch" make[2]: *** [oldconfig] Error 1 make[1]: *** [oldconfig] Error 2 make: *** [oldconfig] Error 2 ryan@mythryan2 ~/dev/linux/linux-git$ ls -al /home/ryan/dev/linux/output/uml/ total 60 drwxr-xr-x 5 ryan ryan 4096 Apr 13 11:15 . drwxr-xr-x 4 ryan ryan 4096 Apr 23 02:38 .. -rw-r--r-- 1 ryan ryan 15445 Apr 13 11:15 .config -rw-r--r-- 1 ryan ryan 1812 Apr 13 11:15 .config.cmd -rw-r--r-- 1 ryan ryan 15855 Mar 29 03:20 .config.old -rw-r--r-- 1 ryan ryan 351 Apr 26 22:56 Makefile drwxr-xr-x 4 ryan ryan 4096 Apr 13 11:15 include drwxr-xr-x 2 ryan ryan 4096 Apr 13 11:15 include2 drwxr-xr-x 4 ryan ryan 4096 Mar 29 03:21 scripts I'm not quite sure what's going on here - but something seems broken. My gut feeling is that arch/um/Kconfig_arch is supposed to be a symlink (or something else magical) pointing at arch/um/Kconfig_i386, but this doesn't seem to be working. I can provide my .config if it matters - but since the above failure happens almost instantly, I don't think it will matter much. Thanks! -- Ryan Anderson <ry...@mi...> |
From: Al V. <vi...@pa...> - 2005-04-27 23:45:20
|
On Tue, Apr 26, 2005 at 11:02:38PM -0400, Ryan Anderson wrote: > I've been seeing a build error when trying to build User Mode Linux on > an x86-32 host (Athlon, fwiw). The kernel I'm building is a 1-day old > pull from git. This error is not new, though. I thought it was merely > an artifact of a patch stuck in a queue at first so I didn't mention it > right away. That's because that stuff is not merged yet. Speaking of which, where does the current UML tree live and who should that series be Cc'ed to? I've got a decent split-up and IMO that should be mergable. Patches are on ftp.linux.org.uk/pub/people/viro/UM*; summary in the end of mail. That's a sanitized and split version of old UML-kbuild patch. There is a bunch of minor fixes not covered by that patchset (ipc.h assuming that there is include/asm-<target>/ipc.h when it should just include the asm-generic/ipc.h and be done with that; ptrace.c broken on amd64 in the part dealing with debug registers; missing include of skas_ptrace.h in amd64 variant of syscalls.h), but that's a separate story. Kbuild-related stuff is all here... Please, review. (0) Make vmlinux.lds.S include appopriate script instead of playing games with symlinks. (1) Use explicit os-... in make dependencies instead of playing with symlinks (symlink in question is still created - it's needed for other things; however, there's no reason to complicate ordering here). (2) Beginning of cross-build fixes. Instead of expecting that mk_user_constants (compiled and executed on the build box) will see the sizeof, etc. for target box, we do what every architecture already does for asm-offsets. Namely, have user-offsets.c compiled *for* *target* into user-offsets.s and sed it into the header with relevant constants. We don't need to reinvent any wheels - all tools are already there. This patch deals with mk_user_constants. It doesn't assume any relationship between target and build environment anymore - we pick all defines we need from user-offsets.h. Later patches will deal with the rest of mk_... helpers in the same way. (3) mk_ptregs converted. Nothing new here, it's the same situation as with mk_user_constants. (4) Ditto for mk_sc (5) The next group of helpers is a bit trickier - they want the constants similar to those in user-offsets.h, but we need target sc.h for it. So we can't put that into user-offsets (sc.h depends on it) and need the second generated header for that stuff (kernel-offsets.h. BFD... (6) mk_thread converted (7) helpers in arch/um/util (mk_task and mk_constants) converted. That's it - none of the helpers depends on build and target being the same architecture anymore. (8) make distclean et.al. are missing arch/um/sys-x86_64/utils; fixed the same way we have it done for sys-i386 counterpart. (9) The last obstacle for cross-builds - bogus -L/usr/lib passed to the final link phase. It's not needed on native build (gcc will do that just fine) and it's wrong on cross-build (the stuff we want is *not* one in /usr/lib and (cross-)gcc knows where to find what we need anyway). We are not calling ld(1) here... Bogus argument removed. At that point we can build working uml-i386 on e.g. alpha. (10) O=... builds support. Very easy, actually. |
From: Ryan A. <ry...@mi...> - 2005-04-28 05:40:25
|
On Thu, Apr 28, 2005 at 12:45:15AM +0100, Al Viro wrote: > On Tue, Apr 26, 2005 at 11:02:38PM -0400, Ryan Anderson wrote: > > I've been seeing a build error when trying to build User Mode Linux on > > an x86-32 host (Athlon, fwiw). The kernel I'm building is a 1-day old > > pull from git. This error is not new, though. I thought it was merely > > an artifact of a patch stuck in a queue at first so I didn't mention it > > right away. > > That's because that stuff is not merged yet. Speaking of which, where does > the current UML tree live and who should that series be Cc'ed to? I think you hit the right people with the Cc: list I started with. > I've got a decent split-up and IMO that should be mergable. Patches are > on ftp.linux.org.uk/pub/people/viro/UM*; summary in the end of mail. > That's a sanitized and split version of old UML-kbuild patch. Thanks, this seems to do the trick. I had an initial problem, but I think I was just working from a directory in a bad state, after nuking my output directory and starting over, it seems to be working just fine. Thanks for the fix, I have another toy to play with this week now. :) -- Ryan Anderson sometimes Pug Majere |
From: Jeff D. <jd...@ad...> - 2005-04-28 21:05:52
|
> That's because that stuff is not merged yet. Speaking of which, where does > the current UML tree live and who should that series be Cc'ed to? My patchset lives at http://user-mode-linux.sf.net/patches.html, and things like this should be CC-ed to me. > I've got a decent split-up and IMO that should be mergable. Patches are > on ftp.linux.org.uk/pub/people/viro/UM*; summary in the end of mail. > That's a sanitized and split version of old UML-kbuild patch. Thanks, merged into my tree. It'll be visible at the above URL next time I push the site out, and I'll merge this and a bunch of other stuff to Linus and Andrew shortly. Jeff |
From: Al V. <vi...@pa...> - 2005-04-28 21:53:47
|
On Thu, Apr 28, 2005 at 04:26:47PM -0400, Jeff Dike wrote: > > That's because that stuff is not merged yet. Speaking of which, where does > > the current UML tree live and who should that series be Cc'ed to? > > My patchset lives at http://user-mode-linux.sf.net/patches.html, and things > like this should be CC-ed to me. > > > I've got a decent split-up and IMO that should be mergable. Patches are > > on ftp.linux.org.uk/pub/people/viro/UM*; summary in the end of mail. > > That's a sanitized and split version of old UML-kbuild patch. > > Thanks, merged into my tree. It'll be visible at the above URL next time > I push the site out, and I'll merge this and a bunch of other stuff to > Linus and Andrew shortly. OK... Out of old UML-kbuild only the chunk in ptrace.c is not covered by that (note that e.g. top-level Makefile is not modified at all in the new version). arch/um/kernel/ptrace.c is a separate story - we need per-arch helper there. |
From: Blaisorblade <bla...@ya...> - 2005-05-01 11:20:34
|
On Thursday 28 April 2005 23:53, Al Viro wrote: > On Thu, Apr 28, 2005 at 04:26:47PM -0400, Jeff Dike wrote: > > > That's because that stuff is not merged yet. Speaking of which, where > > > does the current UML tree live and who should that series be Cc'ed to? > > > > My patchset lives at http://user-mode-linux.sf.net/patches.html, and > > things like this should be CC-ed to me. > > > > > I've got a decent split-up and IMO that should be mergable. Patches > > > are on ftp.linux.org.uk/pub/people/viro/UM*; summary in the end of > > > mail. That's a sanitized and split version of old UML-kbuild patch. > > > > Thanks, merged into my tree. It'll be visible at the above URL next time > > I push the site out, and I'll merge this and a bunch of other stuff to > > Linus and Andrew shortly. > > OK... Out of old UML-kbuild only the chunk in ptrace.c is not covered > by that (note that e.g. top-level Makefile is not modified at all in > the new version). arch/um/kernel/ptrace.c is a separate story - we > need per-arch helper there. For now I've added an #ifdef to re-include that code for x86, while excluding it for x86_64. Also, is that up-to-date wrt. 2.6.12-rc3? I had merged part of your code (at least the most urgent ones). Also, I'm thinking to a generic support for those conditional double includes... I'll post it when it'll be ready. -- Paolo Giarrusso, aka Blaisorblade Skype user "PaoloGiarrusso" Linux registered user n. 292729 http://www.user-mode-linux.org/~blaisorblade |
From: Al V. <vi...@pa...> - 2005-05-01 16:06:54
|
On Sun, May 01, 2005 at 01:30:57PM +0200, Blaisorblade wrote: > For now I've added an #ifdef to re-include that code for x86, while excluding > it for x86_64. Also, is that up-to-date wrt. 2.6.12-rc3? Yes, it is. As for the ptrace.c... IMO the right thing is per-architecture helper here. Such ifdefs are OK when it's just i386 and amd64. As soon as e.g. uml/s390 gets merged or uml/ia64 and uml/ppc get resurrected... |
From: Blaisorblade <bla...@ya...> - 2005-05-02 19:14:51
|
On Sunday 01 May 2005 18:07, Al Viro wrote: > On Sun, May 01, 2005 at 01:30:57PM +0200, Blaisorblade wrote: > > For now I've added an #ifdef to re-include that code for x86, while > > excluding it for x86_64. Also, is that up-to-date wrt. 2.6.12-rc3? > > Yes, it is. As for the ptrace.c... IMO the right thing is > per-architecture helper here. Such ifdefs are OK when it's just i386 and > amd64. As soon as e.g. uml/s390 gets merged or uml/ia64 and uml/ppc get > resurrected... Agreed, I've done it this way to reintroduce for now the code for i386. It's anyway kludgy, since amd64 has too its debug registers to handle (at least it should); it's just that UML does not handle them yet. -- Paolo Giarrusso, aka Blaisorblade Skype user "PaoloGiarrusso" Linux registered user n. 292729 http://www.user-mode-linux.org/~blaisorblade |