Message-ID: <4FA28961.2010407@cs.utoronto.ca>
Date: Thu, 03 May 2012 09:34:25 -0400
From: Ryan Johnson <ryan.johnson@cs.utoronto.ca>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: cygwin@cygwin.com
Subject: Re: [bug] elf.h incomplete
References: <4FA281E3.4020008@samsung.com> <CA+sc5mnHw0CuSzaPiAV4ALQVEKs6_Nc20JrEvu-r121nZU3REg@mail.gmail.com> <4FA2870D.1030604@samsung.com>
In-Reply-To: <4FA2870D.1030604@samsung.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm
Sender: cygwin-owner@cygwin.com
Mail-Followup-To: cygwin@cygwin.com

On 03/05/2012 9:24 AM, Fedin Pavel wrote:
> On 03.05.2012 17:08, Earnie Boyd wrote:
>> To build the Linux kernel
>> under Cygwin requires you have the proper libraries and headers for
>> Linux installed in the cross environment.  It should not be using the
>> libraries and headers provided by the Cygwin build environment.
>  I know about this. My cross-compiler is OK. I cross-build many stuff 
> with it.
>  But Linux kernel build process needs some specific tools, like 
> modpost. They are also built from sources, but they are built to run 
> on the host, not on the target. And of course they use host's 
> (Cygwin's in our case) gcc with its includes.
> These tools operate on newly built ELF files, this is why they use 
> these includes.
I've also run in to this problem, though in my case I just fired up a VM 
to work around it... I needed the VM anyway to actually run the 
newly-built kernel. That said, it would be nice to be able to build on 
the host and just scp the new vmlinuz across...

BTW, libelf.h has all the #defines, but it only #includes them if it 
doesn't find an elf.h, which Cygwin has.

Ryan


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple