Solving the grub-pe2elf problem

Solving the grub-pe2elf problem

[Robert Millan]

Hi,

I thought of a possible solution to the grub-pe2elf problem.  It seems that
it is burdensome to produce ELF binaries on Windows, but building PE binaries
or even PE/win32 executables on GNU/Linux is not (thanks to Mingw32 toolchain
which is available on most distributions).

If building GRUB with "./configure --host=i586-mingw32msvc" works, we could
include win32 binaries in the upcoming 1.97 release.  Other GNU projects do
this as well.  Then we could drop support for toolchains that lack ELF.

It probably doesn't currently build this way, because win32 won't have all
the functions we need, but this can be fixed by importing them from Gnulib,
the GNU compatibility library.

Christian and Bean, are you interested in implementing this?

Other maintainers, is it burdensome to any of you to include these binaries
in official builds?  I suppose it's not, since mingw32 packages are widely
available, but it doesn't hurt to ask :-)

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."

Re: Solving the grub-pe2elf problem

[Vladimir 'phcoder' Serbinenko]

On Fri, Aug 7, 2009 at 3:46 PM, Robert Millan<rmh@aybabtu.com> wrote:
>
> Hi,
>
> I thought of a possible solution to the grub-pe2elf problem.  It seems that
> it is burdensome to produce ELF binaries on Windows, but building PE binaries
> or even PE/win32 executables on GNU/Linux is not (thanks to Mingw32 toolchain
> which is available on most distributions).
>
> If building GRUB with "./configure --host=i586-mingw32msvc" works, we could
> include win32 binaries in the upcoming 1.97 release.  Other GNU projects do
> this as well.  Then we could drop support for toolchains that lack ELF.
>
I don't think that dropping useful features just for the sake of code
to look nice is a good thing. End users wouldn't care if you supply
binaries with or without compilable sources. But you don't let them to
exercise freedom. You can argue that you don't restrict their freedom
it's true but many people may need to taste freedom on a small thing
before changing to (w)holly free system. And this approach attracts
developpers. When I was speaking with developpers around Darwin they
specifically wanted to compile grub with toolchain they already have.
It's why I bothered at all to make grub compilable with Apple
toolchain (I'm personally fine with compiling it from Linux or
FreeBSD). I'm aware of few coders on different skill levels who are
now "tasting" grub and who wouldn't have if I haven't done it
> It probably doesn't currently build this way, because win32 won't have all
> the functions we need, but this can be fixed by importing them from Gnulib,
> the GNU compatibility library.
>
> Christian and Bean, are you interested in implementing this?
>
> Other maintainers, is it burdensome to any of you to include these binaries
> in official builds?  I suppose it's not, since mingw32 packages are widely
> available, but it doesn't hurt to ask :-)
>
> --
> Robert Millan
>
>  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
>  how) you may access your data; but nobody's threatening your freedom: we
>  still allow you to remove your data and not access it at all."
>
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel
>



-- 
Regards
Vladimir 'phcoder' Serbinenko

Personal git repository: http://repo.or.cz/w/grub2/phcoder.git

Re: Solving the grub-pe2elf problem

[Vladimir 'phcoder' Serbinenko]

On Fri, Aug 7, 2009 at 4:01 PM, Vladimir 'phcoder'
Serbinenko<phcoder@gmail.com> wrote:
> On Fri, Aug 7, 2009 at 3:46 PM, Robert Millan<rmh@aybabtu.com> wrote:
>>
>> Hi,
>>
>> I thought of a possible solution to the grub-pe2elf problem.  It seems that
>> it is burdensome to produce ELF binaries on Windows, but building PE binaries
>> or even PE/win32 executables on GNU/Linux is not (thanks to Mingw32 toolchain
>> which is available on most distributions).
>>
If you see pe2elf as being too much of a burden we may switch to
objconv: http://www.agner.org/optimize/. It's already used in
conjunction with Apple Mach-O toolchain. It's not a GNU project but is
licensed under GPL.
> --
> Regards
> Vladimir 'phcoder' Serbinenko
>
> Personal git repository: http://repo.or.cz/w/grub2/phcoder.git
>



-- 
Regards
Vladimir 'phcoder' Serbinenko

Personal git repository: http://repo.or.cz/w/grub2/phcoder.git

Re: Solving the grub-pe2elf problem

[Christian Franke]

Robert Millan wrote:
> I thought of a possible solution to the grub-pe2elf problem.  It seems that
> it is burdensome to produce ELF binaries on Windows, but building PE binaries
> or even PE/win32 executables on GNU/Linux is not (thanks to Mingw32 toolchain
> which is available on most distributions).
>
> If building GRUB with "./configure --host=i586-mingw32msvc" works, we could
> include win32 binaries in the upcoming 1.97 release.  Other GNU projects do
> this as well.  Then we could drop support for toolchains that lack ELF.
>
>   

Which binaries would you like to include?
- kernel.img and modules, and/or
- the grub-*.exe  files (Note: mingw32 .exe != cygwin .exe).?

The problem with the PE->ELF conversion affects build of the *.mod 
files, not the build of the *.exe. The linker script is necessary for 
kernel.img.


> Christian and Bean, are you interested in implementing this?
>
>   

No.

Then building a Cygwin package would rely on the existence of (tested or 
untested?) binaries in the a release tarball. Building packages from SVN 
snapshots would no longer be possible.

I really don't want to spent my open-source-time with such kind of 
feature removal :-)


-- 
Regards,
Christian Franke

Re: Solving the grub-pe2elf problem

[Christian Franke]

Vladimir 'phcoder' Serbinenko wrote:
> If you see pe2elf as being too much of a burden we may switch to
> objconv: http://www.agner.org/optimize/. It's already used in
> conjunction with Apple Mach-O toolchain. It's not a GNU project but is
> licensed under GPL.
>   

Thanks for the hint, I will try objconv it soon.

-- 
Regards,
Christian Franke

Re: Solving the grub-pe2elf problem

[Bean]

Hi,

You could also check out my new object format at
http://github.com/bean123/grub, lib branch. It supports conversion of
pe/elf/mach-o object file to a grub specific format, so that you can
use native build tool in Linux/OSX/Windows, no need for linker and
converter. It also reduce compile time by half and generate module
file much smaller that the current format.

On Sat, Aug 8, 2009 at 12:20 AM, Christian
Franke<Christian.Franke@t-online.de> wrote:
> Vladimir 'phcoder' Serbinenko wrote:
>>
>> If you see pe2elf as being too much of a burden we may switch to
>> objconv: http://www.agner.org/optimize/. It's already used in
>> conjunction with Apple Mach-O toolchain. It's not a GNU project but is
>> licensed under GPL.
>>
>
> Thanks for the hint, I will try objconv it soon.
>
> --
> Regards,
> Christian Franke
>
>
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel
>



-- 
Bean

Re: Solving the grub-pe2elf problem

[Robert Millan]

On Fri, Aug 07, 2009 at 04:06:11PM +0200, Vladimir 'phcoder' Serbinenko wrote:
> On Fri, Aug 7, 2009 at 4:01 PM, Vladimir 'phcoder'
> Serbinenko<phcoder@gmail.com> wrote:
> > On Fri, Aug 7, 2009 at 3:46 PM, Robert Millan<rmh@aybabtu.com> wrote:
> >>
> >> Hi,
> >>
> >> I thought of a possible solution to the grub-pe2elf problem.  It seems that
> >> it is burdensome to produce ELF binaries on Windows, but building PE binaries
> >> or even PE/win32 executables on GNU/Linux is not (thanks to Mingw32 toolchain
> >> which is available on most distributions).
> >>
> If you see pe2elf as being too much of a burden we may switch to
> objconv: http://www.agner.org/optimize/. It's already used in
> conjunction with Apple Mach-O toolchain. It's not a GNU project but is
> licensed under GPL.

I don't understand this.  Why is a requirement to install GNU binutils
unreasonable, whereas a requirement to install objconv is not?

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."

Re: Solving the grub-pe2elf problem

[Pavel Roskin]

On Fri, 2009-08-07 at 22:39 +0200, Robert Millan wrote:

> I don't understand this.  Why is a requirement to install GNU binutils
> unreasonable, whereas a requirement to install objconv is not?

Installing binutils can break the existing toolchain.  Installing
objconv should not.

It's a good idea, as it would unify Apple and Cygwin support to some
degree.

-- 
Regards,
Pavel Roskin

Re: Solving the grub-pe2elf problem

[Pavel Roskin]

On Fri, 2009-08-07 at 15:46 +0200, Robert Millan wrote:

> Other maintainers, is it burdensome to any of you to include these binaries
> in official builds?  I suppose it's not, since mingw32 packages are widely
> available, but it doesn't hurt to ask :-)

I would prefer not to do a binary build at this stage.  Especially
Windows users are at risk of messing things up if the entry barrier is
lowered too much.

-- 
Regards,
Pavel Roskin

Re: Solving the grub-pe2elf problem

[Christian Franke]

Bean wrote:
> You could also check out my new object format at
> http://github.com/bean123/grub, lib branch. It supports conversion of
> pe/elf/mach-o object file to a grub specific format, so that you can
> use native build tool in Linux/OSX/Windows, no need for linker and
> converter. It also reduce compile time by half and generate module
> file much smaller that the current format.
>
>   

Tested successfully on Cygwin - Nice work!

-- 
Regards,
Christian Franke

Re: Solving the grub-pe2elf problem

[Robert Millan]

On Sat, Aug 08, 2009 at 12:49:27AM -0400, Pavel Roskin wrote:
> On Fri, 2009-08-07 at 22:39 +0200, Robert Millan wrote:
> 
> > I don't understand this.  Why is a requirement to install GNU binutils
> > unreasonable, whereas a requirement to install objconv is not?
> 
> Installing binutils can break the existing toolchain.  Installing
> objconv should not.
> 
> It's a good idea, as it would unify Apple and Cygwin support to some
> degree.

I would prefer if we didn't feed the NIH syndrome in those two platforms (the
rest of the world has settled on ELF, and it is still difficult for users of
those two OSes to produce that format).

That said, switching to objconv is an improvement.  I have nothing against it.

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."