[bug] elf.h incomplete

[bug] elf.h incomplete

[Fedin Pavel]

  Why is elf.h include incomplete in Cygwin?
  I am cross-compiling Linux kernel under Cygwin, and i had to patch 
modpost utility, adding missing R_xxx definitions for some reloc types.
Since kernel v3 i have to add some more definitions, as well as patch 
one more utility, recordmcount. So, amount of patching grows.
Can Cygwin's elf.h simply include all missing definitions instead? I 
know that ELF is not a home format for Cygwin, but many things being 
cross-build seem to rely on this include.

-- 
  Kind regards
  Pavel Fedin
  Expert engineer, Samsung Moscow research center


--
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

Re: [bug] elf.h incomplete

[Earnie Boyd]

On Thu, May 3, 2012 at 9:02 AM, Fedin Pavel wrote:
>  Why is elf.h include incomplete in Cygwin?
>  I am cross-compiling Linux kernel under Cygwin, and i had to patch modpost
> utility, adding missing R_xxx definitions for some reloc types.
> Since kernel v3 i have to add some more definitions, as well as patch one
> more utility, recordmcount. So, amount of patching grows.
> Can Cygwin's elf.h simply include all missing definitions instead? I know
> that ELF is not a home format for Cygwin, but many things being cross-build
> seem to rely on this include.

If you are using any Cygwin header for the build of a system that is
to be hosted in some other OS then I suspect you do not know how to
properly do a cross build environment.  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.

-- 
Earnie
-- https://sites.google.com/site/earnieboyd

--
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

Re: [bug] elf.h incomplete

[Fedin Pavel]

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.

-- 
  Kind regards
  Pavel Fedin
  Expert engineer, Samsung Moscow research center


--
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

Re: [bug] elf.h incomplete

[Ryan Johnson]

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

Re: [bug] elf.h incomplete

[Fedin Pavel]

On 03.05.2012 17:34, Ryan Johnson wrote:
> 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...

  I found using VM too uncomfortable and limiting, this is why i 
switched to Cygwin. I have real ARM HW here to actually run the built 
code. And Cygwin NFS server helps a lot with this.

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

  There's Cygwin package. But i checked it, it doesn't have reloc 
definitions either. So:
a) Not an option anyway.
b) Completing system-wide elf.h would solve all problems at once, and 
increase compatibility. Anyway Cygwin's aim is to be as close to UNIX 
environment as possible, to make things working out of the box. Or am i 
wrong here ?

-- 
  Kind regards
  Pavel Fedin
  Expert engineer, Samsung Moscow research center


--
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

Re: [bug] elf.h incomplete

[marco atzeri]

On 5/3/2012 3:59 PM, Fedin Pavel wrote:
> On 03.05.2012 17:34, Ryan Johnson wrote:
>> 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...
>
> I found using VM too uncomfortable and limiting, this is why i switched
> to Cygwin. I have real ARM HW here to actually run the built code. And
> Cygwin NFS server helps a lot with this.
>
>> BTW, libelf.h has all the #defines, but it only #includes them if it
>> doesn't find an elf.h, which Cygwin has.
>
> There's Cygwin package. But i checked it, it doesn't have reloc
> definitions either. So:
> a) Not an option anyway.
> b) Completing system-wide elf.h would solve all problems at once, and
> increase compatibility. Anyway Cygwin's aim is to be as close to UNIX
> environment as possible, to make things working out of the box. Or am i
> wrong here ?
>

as usual
http://cygwin.com/acronyms/#PTC

--
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

Re: [bug] elf.h incomplete

[Christopher Faylor]

On Thu, May 03, 2012 at 04:04:32PM +0200, marco atzeri wrote:
>On 5/3/2012 3:59 PM, Fedin Pavel wrote:
>> On 03.05.2012 17:34, Ryan Johnson wrote:
>>> 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...
>>
>> I found using VM too uncomfortable and limiting, this is why i switched
>> to Cygwin. I have real ARM HW here to actually run the built code. And
>> Cygwin NFS server helps a lot with this.
>>
>>> BTW, libelf.h has all the #defines, but it only #includes them if it
>>> doesn't find an elf.h, which Cygwin has.
>>
>> There's Cygwin package. But i checked it, it doesn't have reloc
>> definitions either. So:
>> a) Not an option anyway.
>> b) Completing system-wide elf.h would solve all problems at once, and
>> increase compatibility. Anyway Cygwin's aim is to be as close to UNIX
>> environment as possible, to make things working out of the box. Or am i
>> wrong here ?
>>
>
>as usual
>http://cygwin.com/acronyms/#PTC

Right.  I've noticed the incompleteness of elf.h from time to time too but
extending it would be tedious since you can't just cut/paste from a GPLv*
file.  Maybe one of the BSDs has something more complete these days?  We
could use one of those.

cgf

--
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

Licensing questions (was: [bug] elf.h incomplete)

[Fedin Pavel]

On 03.05.2012 19:24, Christopher Faylor wrote:
> Right.  I've noticed the incompleteness of elf.h from time to time too but
> extending it would be tedious since you can't just cut/paste from a GPLv*
> file.  Maybe one of the BSDs has something more complete these days?
  By the way, interesting question. It raises up from time to time here 
and there, but noone gives the answer...
  Is there any strict definition of "derived work"?
  The problem is: we have some #define in GPLed code. And i want to make 
some non-GPLed code interoperable. Consequently, i need the same 
#define. Exactly the our case. Of course i could copy-paste the code, 
and it would definitely be "derived work". But what if i don't 
copy-paste this code, but retype it by hands? Still a copy? Well, add 
some more cleanup. Take a piece of paper, write down all names and 
values. Drink lots of whiskey (wine, vodka) to erase own memory ;-) Next 
day take this paper and write own include. Is it still "derived work" ?
  But, after all, we still have only names and values, nothing more, and 
no matter how we made our version. Does "using the same name" 
automatically mean "derived work"? But in this case IMHO this as a 
nonsense. There's even an anecdote about Microsoft having to opensource 
all their stuff because their code uses GPLed "i++" fragment. Well, 
copyright infringement applies here as well, based on the reverse claim. :)
  So - where are limits of "derived work" ? And should this meaning be 
applied to public visible (like includes, APIs, etc) stuff at all ? 
Because if the answer is yes, this effectively forbids existence of 
alternate solutions to anything at all.
  After all, such reimplementations fall into "fair use" category.

  P.S. I would do it and submit a patch, but here at Samsung any code 
submitted upstream requires review and approval, in order to prevent 
classified information leak. This is of course possible, but this would 
be long way for such a trivial thing. You (Cygwin team) would fix it 
yourself faster.

-- 
  Kind regards
  Pavel Fedin
  Expert engineer, Samsung Moscow research center


--
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

Re: Licensing questions

[Ryan Johnson]

On 03/05/2012 11:38 PM, Fedin Pavel wrote:
> On 03.05.2012 19:24, Christopher Faylor wrote:
>> Right.  I've noticed the incompleteness of elf.h from time to time 
>> too but
>> extending it would be tedious since you can't just cut/paste from a 
>> GPLv*
>> file.  Maybe one of the BSDs has something more complete these days?
>  By the way, interesting question. It raises up from time to time here 
> and there, but noone gives the answer...
>  Is there any strict definition of "derived work"?
>  The problem is: we have some #define in GPLed code. And i want to 
> make some non-GPLed code interoperable. Consequently, i need the same 
> #define. Exactly the our case. Of course i could copy-paste the code, 
> and it would definitely be "derived work". But what if i don't 
> copy-paste this code, but retype it by hands? Still a copy? Well, add 
> some more cleanup. Take a piece of paper, write down all names and 
> values. Drink lots of whiskey (wine, vodka) to erase own memory ;-) 
> Next day take this paper and write own include. Is it still "derived 
> work" ?
>  But, after all, we still have only names and values, nothing more, 
> and no matter how we made our version. Does "using the same name" 
> automatically mean "derived work"? But in this case IMHO this as a 
> nonsense. There's even an anecdote about Microsoft having to 
> opensource all their stuff because their code uses GPLed "i++" 
> fragment. Well, copyright infringement applies here as well, based on 
> the reverse claim. :)
Well, according to the EU commission's very recent ruling, at least, you 
can't copyright APIs, which I would consider this elf stuff to be. 
IANAL, tho.

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