i386 install.sh script doesn't handle cross-compiling well

[Robert P. J. Day]

(another bit of fallout from yesterday's cross-compiling adventure
... if this is a bit incoherent, it's late.)

in cross-compiling the kernel for x86_64, i had the location of the
toolchain in my search path and all of my config and build commands
were of the form:

$ make ARCH=x86_64 CROSS_COMPILE=x86_64- ...

for targets like

... defconfig
... menuconfig
... bzImage
... modules

so far, so good.

then, even though it was certainly redundant, i left the ARCH= and
CROSS_COMPILE= make variables there when i did:

# make ... modules_install
# make ... install

first, i'm guessing that, regardless of architecture or
cross-compile, you can always run simply "make modules_install",
correct? is there anything about installing modules that needs to
know about architecture or cross compiling? in any event, having
those variables there didn't seem to have any effect, but i'm assuming
they have no value for this target, right?

on the other hand, it *did* have an effect on doing the kernel
install. running

# make ARCH=x86_64 CROSS_COMPILE=x86_64- install

invoked the script arch/x86_64/boot/install.sh, which consists
entirely of:

#!/bin/sh
. $srctree/arch/i386/boot/install.sh

ok, so off we go to the i386 install script, which ends with the
following:
======================================================================
...
# User may have a custom install script

if [ -x ~/bin/${CROSS_COMPILE}installkernel ]; then exec ~/bin/${CROSS_COMPILE}installkernel "$@"; fi
if [ -x /sbin/${CROSS_COMPILE}installkernel ]; then exec /sbin/${CROSS_COMPILE}installkernel "$@"; fi

# Default install - same as make zlilo

if [ -f $4/vmlinuz ]; then
mv $4/vmlinuz $4/vmlinuz.old
fi

if [ -f $4/System.map ]; then
mv $4/System.map $4/System.old
fi

cat $2 > $4/vmlinuz
cp $3 $4/System.map

if [ -x /sbin/lilo ]; then /sbin/lilo; else /etc/lilo/install; fi
=====================================================================

so if you're doing a regular (i386) install, CROSS_COMPILE isn't set
and you call the regular /sbin/installkernel.

OTOH, if you're doing an x86_64 install and you accidentally leave
CROSS_COMPILE in the "make" line, that script will obviously fail to
find the appropriate (custom) version of "installkernel", then
continue down until it tries to run "lilo". ugh. and that's what
happened when i ran

# make ... CROSS_COMPILE=x86_64- install

and eventually got the error message:

... /etc/lilo/install: No such file or directory.

it just seems sloppy to have had that script eventually work its way
down to trying to run lilo on this system, when lilo is not even
installed.

thoughts?

rday

--
========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA

http://fsdev.net/wiki/index.php?title=Main_Page
========================================================================

--
To unsubscribe from this list: send an email with
"unsubscribe kernelnewbies" to eca...@nl.linux.org
Please read the FAQ at http://kernelnewbies.org/FAQ

[Erik Mouw]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tue, May 01, 2007 at 03:37:31AM -0400, Robert P. J. Day wrote:
>
> (another bit of fallout from yesterday's cross-compiling adventure
> ... if this is a bit incoherent, it's late.)
>
> in cross-compiling the kernel for x86_64, i had the location of the
> toolchain in my search path and all of my config and build commands
> were of the form:
>
> $ make ARCH=x86_64 CROSS_COMPILE=x86_64- ...
>
> for targets like
>
> ... defconfig
> ... menuconfig
> ... bzImage
> ... modules
>
> so far, so good.
>
> then, even though it was certainly redundant, i left the ARCH= and
> CROSS_COMPILE= make variables there when i did:
>
> # make ... modules_install
> # make ... install
>
> first, i'm guessing that, regardless of architecture or
> cross-compile, you can always run simply "make modules_install",

No, "modules_install" also cd's to arch/$ARCH and installs modules over
there. Same for the "install" target, but in this case to install the
actual kernel (and running lilo, or whatever way to make the new kernel
bootable).

Erik

- --
They're all fools. Don't worry. Darwin may be slow, but he'll
eventually get them. -- Matthew Lammers in alt.sysadmin.recovery
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFGN24D/PlVHJtIto0RAvDaAJwOOhsjHEmHKTvbqV6t9orpSYjy5ACfSYbh
5UO+raI+9ixcGscV2AwEfnU=
=s9v4
-----END PGP SIGNATURE-----