hi,
On Feb 24, 3:15pm, james rich wrote:
> Subject: Re: building 2.4.2 (with XFS) fails
> I built a stock kernel 2.4.2 with no problems so the failure below is
> definately something related to the XFS patches. Unfortunately I don't
> know the cause of the build failure. Is everyone here building on RH7?
no - I'm not, but according to the survey it seems many folk
trying out XFS (and answering the survey) are using one or
other version of RedHat though.
> I'm using Slackware 7.1. It seems that these patches would need to build
according to the survey, there have been a few other people
using Slackware (not sure which versions).
> on most distros before reaching release level. Let me know if I can do
> something (happy to test stuff).
>
> On Fri, 23 Feb 2001, james rich wrote:
> > When building 2.4.2 with XFS patches the build fails with errors that
> > don't seem related to XFS (that's why the crosspost):
> >
> > gcc -V egcs-2.91.66 -D__KERNEL__ -I/usr/src/linux/include -Wall
> > -Wstrict-prototypes -O2 -fno-strict-aliasing -fomit-frame-pointer -pipe
> > -march=i686 -c -o dec_and_lock.o dec_and_lock.c
> > rm -f lib.a
> > ar rcs lib.a checksum.o old-checksum.o delay.o usercopy.o getuser.o
> > putuser.o iodebug.o memcpy.o dec_and_lock.o
> > make[2]: Leaving directory `/usr/src/linux-2.4-xfs/linux/arch/i386/lib'
> > make[1]: Leaving directory `/usr/src/linux-2.4-xfs/linux/arch/i386/lib'
> > make[1]: Entering directory `/usr/src/linux-2.4-xfs/linux'
> > ld -m elf_i386 -T /usr/src/linux/arch/i386/vmlinux.lds -e stext
> > arch/i386/kernel/head.o arch/i386/kernel/init_task.o init/main.o
> > init/version.o --start-group arch/i386/kernel/kernel.o arch/i386/mm/mm.o
> > kernel/kernel.o mm/mm.o fs/fs.o ipc/ipc.o drivers/block/block.o
> > drivers/char/char.o drivers/misc/misc.o drivers/net/net.o
> > drivers/media/media.o drivers/parport/driver.o drivers/char/drm/drm.o
> > drivers/ide/idedriver.o drivers/scsi/scsidrv.o drivers/cdrom/driver.o
> > drivers/sound/sounddrivers.o drivers/pci/driver.o drivers/video/video.o
> > drivers/i2c/i2c.o drivers/md/mddev.o net/network.o
> > /usr/src/linux/arch/i386/lib/lib.a /usr/src/linux/lib/lib.a
> > /usr/src/linux/arch/i386/lib/lib.a --end-group -o vmlinux
> > drivers/char/char.o: In function `vt_ioctl':
> > drivers/char/char.o(.text+0x96fb): undefined reference to `key_maps'
from my build area, it seems I'm picking up the `key_maps'
symbol from drivers/char/defkeymap.o...
$ nm drivers/char/defkeymap.o | grep key_maps
00000700 D key_maps
drivers/char/defkeymap.c should exist and should have been
generated by the last line of drivers/char/Makefile.
do you have a drivers/char/defkeymap.c file? if so, do you
have the drivers/char/defkeymap.o file? if so, does it
contain the `key_maps' symbol? if so, my theory is in
trouble. ;-)
you should also see a line something like this in your make
output (would be well before the error I think) ...
ld -m elf_i386 -r -o char.o tty_io.o n_tty.o tty_ioctl.o \
^^^^^^^^
mem.o raw.o pty.o misc.o random.o vt.o vc_screen.o consolemap.o\
consolemap_deftbl.o console.o selection.o serial.o keyboard.o \
defkeymap.o pc_keyb.o sysrq.o
^^^^^^^^^^^
...that char.o is drivers/char/char.o which seems to not have
`key_maps' in your case.
> >
> > Any ideas what is wrong?
> >
I have a vague recollection of this .c file being checked
into the tree (accidentally) from day1, but it was removed
quite some time ago ... perhaps you're using a workarea
updated from a while ago & this is somehow permuting your
build? (clutching at straws here).
If you have a drivers/char/defkeymap.c file, you could try
deleting it & allow a fresh build to regenerate it. since
your non-XFS 2.4.2 build works, this should too (there are
no XFS changes around this code that I'm aware of).
hope this helps.
cheers.
--
Nathan
|