public inbox for linux-ia64@vger.kernel.org
 help / color / mirror / Atom feed
From: Dan Kegel <dank@kegel.com>
To: linux-ia64@vger.kernel.org
Subject: offsets.h and 32 -> 64 bit cross-compiling
Date: Mon, 02 Feb 2004 01:19:08 +0000	[thread overview]
Message-ID: <401DA58C.8070105@kegel.com> (raw)

I recently updated my toolchain build script (http://kegel.com/crosstool)
to use linux-2.4.21 headers instead of linux-2.4.20, and can no longer generate
an x86 -> ia64 cross toolchain.  The new kernel source tree no longer has
asm-ia64/offsets.h, since that is now generated from other .h files at
'make dep' time.   Keith Owens noticed back in Sept '03 that this
had a chicken-and-egg problem when cross-compiling, and posted
http://www.gelato.unsw.edu.au/linux-ia64/0309/6667.html to fix that.

Sadly, that fix seems to be insufficient.
On my x86 build machine, 'make ARCH=ia64 dep' for linux-2.4.21 now fails with errors like

gcc -g -O2 -Wall -D__KERNEL__ -I/cross/linux-2.4.21/include -DKBUILD_BASENAME= print_offsets.c -o print_offsets
In file included ... from print_offsets.c:17:
/cross/linux-2.4.21/include/asm/page.h:75: warning: width of `off' exceeds its type
In file included ... from print_offsets.c:17:
/cross/linux-2.4.21/include/asm/byteorder.h: In function `__ia64_swab32':
/cross/linux-2.4.21/include/asm/byteorder.h:23: warning: right shift count >= width of type

(I suspect this has not changed in newer 2.4 kernels.)
Note that plain old gcc is used to compile this file, since it
has to generate an executable that can run on the build machine.

This doesn't seem to work when the build machine and the target architecture
have different bit widths!
Looking at the first error, page.h uses 'unsigned long' to indicate a 64 bit integer.
That could be fixed by using __u64 or uint64_t, assuming we change
<asm-*/types.h>'s definition of __u64 to work when cross-compiling.
To check whether the fix is complete, one would compare offsets.h
generated by a cross-compile run with one generated by a native run.

Has anyone looked at fixing this yet?  I'm going to drop back to
building with linux-2.4.20 headers or something for a while,
but it'd be nice to have this actually work sometime, and I'm
willing to do the work if nobody else has yet.

Thanks,
Dan

             reply	other threads:[~2004-02-02  1:19 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-02-02  1:19 Dan Kegel [this message]
2004-02-10 21:16 ` offsets.h and 32 -> 64 bit cross-compiling David Mosberger
2004-02-11  5:59 ` Dan Kegel
2004-02-11  6:17 ` Keith Owens

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=401DA58C.8070105@kegel.com \
    --to=dank@kegel.com \
    --cc=linux-ia64@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox