All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mitch <Mitch@0Bits.COM>
To: jdike@addtoit.com, linux-kernel@vger.kernel.org,
	blaisorblade@yahoo.it, penberg@cs.helsinki.fi
Subject: Re: More uml build failures on 2.16.19-rc3 and 2.6.18.1
Date: Sat, 28 Oct 2006 15:21:34 +0400	[thread overview]
Message-ID: <45433D3E.3070109@0Bits.COM> (raw)

Hi Jeff, all,

Sorry for the dealy but i've been out of the country.

Anyhow i did some investigation and i've figured out the bug.

Essentially if you try to compile a UML kernel on a 2.6.18.1 or above 
*host* kernel it will fail with the error messages shown (essentially 
offsetof macro undefined) because between 2.6.18 and 2.6.18.1 that macro 
in /usr/include/linux/stddef.h is now wrapped in a #ifdef __KERNEL__ . 
However since UML doesn't build it's sources with that defined we get an 
undefined macro and a build failure.

So i'm partly right and partly wrong in my statement below. Yes i did 
compile a guest UML kernel 2.6.18 fine on host kernel of 2.6.18, and i 
believe i will be able to compile 2.6.18.1 and above also on a host 
kernel of 2.6.18 but if i change my host kernel to 2.6.18.1 or above all 
UML guest builds will fail.

Can someone confirm they can build guest UML kernels on a host kernel >= 
2.6.18.1 ??

Thanks
M

-------- Original Message --------
Subject: Re: More uml build failures on 2.16.19-rc3 and 2.6.18.1
Date: Wed, 25 Oct 2006 11:41:30 -0400
From: Jeff Dike <jdike@addtoit.com>
To: Mitch <Mitch@0Bits.COM>
CC: linux-kernel@vger.kernel.org
References: <453E7F07.9010804@0Bits.COM>

On Wed, Oct 25, 2006 at 01:00:55AM +0400, Mitch wrote:
> I've definetly not done any such change on my machine. Remember with the 
> same compile, same environment, if i go back to 2.6.18 i can build uml 
> fine. If i move to 2.6.18.1 or above it breaks...

You're sure about that?  I just looked through the 2.6.18.1 changelog and
I see nothing that would cause this.

> I do notice my gcc stddef does have this defined
> 
> % grep offsetof /usr/lib/gcc/i686-linux/4.0.3/include/stddef.h
> #define offsetof(TYPE, MEMBER) __builtin_offsetof (TYPE, MEMBER)

I would do a -E build and make sure that this header, or another one that
defines offsetof is getting pulled in.

				Jeff

             reply	other threads:[~2006-10-28 11:22 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-10-28 11:21 Mitch [this message]
2006-10-29 17:57 ` [uml-devel] More uml build failures on 2.16.19-rc3 and 2.6.18.1 Blaisorblade
2006-10-29 17:57   ` Blaisorblade
  -- strict thread matches above, loose matches on Subject: below --
2006-10-24 21:00 Mitch
2006-10-25 15:41 ` Jeff Dike
2006-10-24  8:34 Mitch
2006-10-24  7:31 Mitch
2006-10-24  7:41 ` Pekka Enberg
2006-10-24 13:20 ` Jeff Dike

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=45433D3E.3070109@0Bits.COM \
    --to=mitch@0bits.com \
    --cc=blaisorblade@yahoo.it \
    --cc=jdike@addtoit.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=penberg@cs.helsinki.fi \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.