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 <[email protected]>
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.
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
> 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
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.
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
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...
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