Gecko and Wine issue

[Jason L Tibbitts III]

I just wanted to let you folks know about a current discussion going on
between various Wine developers.  Wine uses Gecko, the Mozilla rendering
engine, as a replacement for whatever is in Windows.  Currently at issue
is how a user of Wine actually gets gecko on their system.  It can be
downloaded at wine startup, which is problematic for various reasons, or the
distro can package it.  But what's needed are the actual win32 gecko
libraries, not a native Linux version, which sort of involves
using mingw and cross-compiling.

The alternative of just sticking the cab in an rpm is obviously not
acceptable for Fedora.

The relevant thread starts at
http://www.winehq.org/pipermail/wine-devel/2009-November/079744.html

There's a wiki page http://wiki.winehq.org/Gecko which talks about
distros which package Gecok "properly", where that seems to be just
dropping a binary in the right place without any regard for how its
built or how that conflicts with a distro's goals and requirements,
although there is a complaint about this at
http://www.winehq.org/pipermail/wine-devel/2009-November/079819.html
There's also mention about mingw needing patching to handle building
gecko at
http://www.winehq.org/pipermail/wine-devel/2009-November/079851.html

Feel free to ignore me entirely; I just wanted to bring this to the
attention of folks who might understand things far better than I.

 - J<

[Erik van Pienbroek]

Op dinsdag 17-11-2009 om 14:10 uur [tijdzone -0600], schreef Jason L
Tibbitts III:
>  Currently at issue
>  is how a user of Wine actually gets gecko on their system.  It can be
>  downloaded at wine startup, which is problematic for various reasons, or the
>  distro can package it.  But what's needed are the actual win32 gecko
>  libraries, not a native Linux version, which sort of involves
>  using mingw and cross-compiling. 
Hi Jason,

With our MinGW toolchain it should be perfectly possible to build the
wine-gecko library from source. The instructions at
http://wiki.winehq.org/BuildingWineGecko are all that we need to create
a .spec file for it.

The only thing that needs attention is the contents of the wintools.zip
file. That file contains some binaries (like gmake.exe) which are
required for compilation (however, this is targeted for native Win32
environments). Those binaries probably aren't required when
cross-compiling but that's something which should be investigated.

If you're interesting I can try to create a .spec file for it. However,
if you want to have it in Fedora I don't want to be it's primary
maintainer (but co-maintaining is fine with me).

Regards,

Erik van Pienbroek

PS. Your message arrived in the moderation queue of this mailing list in
the first place because you're not subscribed yet. I added you to the
white-list for now but you might to consider subscribing. This list is
quite low volume.

[Erik van Pienbroek]

Op dinsdag 17-11-2009 om 21:35 uur [tijdzone +0100], schreef Erik van
Pienbroek:
>  With our MinGW toolchain it should be perfectly possible to build
> the
>  wine-gecko library from source. The instructions at
>  http://wiki.winehq.org/BuildingWineGecko are all that we need to create
>  a .spec file for it. 
>  If you're interested I can try to create a .spec file for it.
> However,
>  if you want to have it in Fedora I don't want to be it's primary
>  maintainer (but co-maintaining is fine with me). 
Hi,

Creating a .spec file for wine-mozilla turned out to be easier than
expected. I just managed to get everything packaged with the exception
of the final step: creating a .cab file. We can't do that because
there's no open source tool to create .cab files. So now I created a
package which puts all the gecko files in the
folder /usr/share/wine/gecko. We might want to patch Wine so that it
uses the gecko files directly instead of unpacking the .cab file on
first use.

Some small patches were required to get everything compiled (due to the
use of a more recent GCC and some missing w32api declarations) but in
the end I managed to get a working environment (by symlinking
~/.wine/drive_c/windows/system32/gecko/1.0.0/wine_gecko
to /usr/share/wine/gecko). I tested this with Wine's iexplore.exe and
didn't encounter anything unusual.

Regarding my comment on not wanting to be primary maintainer of this
package: I'd prefer it if somebody else who has a closer connection to
upstream (the current wine maintainer?) maintains this as I don't really
have the time to monitor for new releases. Whenever MinGW specific
issues arise I'm willing to help with resolving those (hence the
co-maintainer offer).

The Koji build can be found at
http://koji.fedoraproject.org/koji/taskinfo?taskID=1815495
As scratch builds tend to get removed quite quickly I also uploaded the
SRPM to my personal server:
http://www.ftd4linux.nl/contrib/mingw32-wine-gecko-1.0.0-1.fc12.src.rpm
and the .spec file to
http://www.ftd4linux.nl/contrib/mingw32-wine-gecko.spec
Feel free to put them up for review

Op woensdag 18-11-2009 om 11:18 uur [tijdzone +0000], schreef Richard
W.M. Jones:
>  The only note of caution I would add is that Mozilla stuff uses its
>  own crazy-stupid build system which doesn't really understand
>  cross-compilation properly (or much else for that matter).  For
>  example, I had a lot of problems cross-compiling NSS and NSPR. 
It's strange that you had these issues. NSS and NSPR just compiled here fine without
any manual fiddling.
Perhaps it's caused by the fact that wine-gecko is a forked copy of the gecko engine
and is
aimed for cross-compilation in the first place.

>  On the subject of: http://wiki.winehq.org/BuildingWineGecko
>  Note that Fedora MinGW already supplies binutils, runtime, w32api, gcc
>  packages.  So any instructions about installing those can be
>  disregarded.  They claim to need gcc 3 (which we don't supply), but
>  looking at the supposed bug[1] it seems that this is issue should be
>  fixed in the gcc 4.4.3 (we don't yet have this, but gcc version bumps
>  are usually simple). 
To build this package all I needed was the basic tools: binutils, runtime, w32api and gcc
At that wiki page there was some talk about a GCC bug, but I didn't run into it
as everything compiled just fine and also runs fine in Wine.

Regards,

Erik van Pienbroek

[Andreas Bierfert]

On Thu, 19 Nov 2009 07:19:24 +0100
Erik van Pienbroek <erik(a)vanpienbroek.nl&gt; wrote:

>  Creating a .spec file for wine-mozilla turned out to be easier than
>  expected. I just managed to get everything packaged with the exception
>  of the final step: creating a .cab file. We can't do that because
>  there's no open source tool to create .cab files. So now I created a
>  package which puts all the gecko files in the
>  folder /usr/share/wine/gecko. We might want to patch Wine so that it
>  uses the gecko files directly instead of unpacking the .cab file on
>  first use. 
Sounds great. Thanks for getting it underway. I will take some time to test this
over the weekend and see how it can be integrated into the wine package.
This is especially helpful because as of the current release gecko will be
downloaded automagically upon creation/upgrade if ~/.wine.

>  Regarding my comment on not wanting to be primary maintainer of this
>  package: I'd prefer it if somebody else who has a closer connection to
>  upstream (the current wine maintainer?) maintains this as I don't really
>  have the time to monitor for new releases. Whenever MinGW specific
>  issues arise I'm willing to help with resolving those (hence the
>  co-maintainer offer). 
I'd be willing to maintain it, however I am not a MinGW expert in any way.
I would welcome doing it in a co-maintained fashion.

Great to see how MinGW stuff is evolving in fedora.

Best Regards,
Andreas
-- 
Andreas Bierfert, M.Sc.        | http://awbsworld.de      | GPG: C58CF1CB
andreas.bierfert(a)lowlatency.de | http://lowlatency.de     | signed/encrypted
phone: [phone]        | cell: [phone]    | mail preferred

[Richard W.M. Jones]

On Thu, Nov 19, 2009 at 07:19:24AM +0100, Erik van Pienbroek wrote:
>  Op woensdag 18-11-2009 om 11:18 uur [tijdzone +0000], schreef
> Richard
>  W.M. Jones:
>  > The only note of caution I would add is that Mozilla stuff uses its
>  > own crazy-stupid build system which doesn't really understand
>  > cross-compilation properly (or much else for that matter).  For
>  > example, I had a lot of problems cross-compiling NSS and NSPR.
>  
>  It's strange that you had these issues. NSS and NSPR just compiled here fine without
> any manual fiddling.
>  Perhaps it's caused by the fact that wine-gecko is a forked copy of the gecko engine
> and is
>  aimed for cross-compilation in the first place. 
If they've removed the stupid stuff in upstream Mozilla, then that can
only be a Good Thing :-)

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-p2v converts physical machines to virtual machines.  Boot with a
live CD or over the network (PXE) and turn machines into Xen guests.
http://et.redhat.com/~rjones/virt-p2v

[Richard W.M. Jones]

On Tue, Nov 17, 2009 at 02:10:42PM -0600, Jason L Tibbitts III wrote:
>  I just wanted to let you folks know about a current discussion going
> on
>  between various Wine developers.  Wine uses Gecko, the Mozilla rendering
>  engine, as a replacement for whatever is in Windows.  Currently at issue
>  is how a user of Wine actually gets gecko on their system.  It can be
>  downloaded at wine startup, which is problematic for various reasons, or the
>  distro can package it.  But what's needed are the actual win32 gecko
>  libraries, not a native Linux version, which sort of involves
>  using mingw and cross-compiling. 
As Erik said, Fedora MinGW should be able to cross-compile Gecko just
fine.  We are already able to compile large C++ graphical apps
(eg. Inkscape, FlightGear etc.)

The only note of caution I would add is that Mozilla stuff uses its
own crazy-stupid build system which doesn't really understand
cross-compilation properly (or much else for that matter).  For
example, I had a lot of problems cross-compiling NSS and NSPR.  You
can see the sorts of troubles we had by looking at the spec files:

http://git.annexia.org/?p=fedora-mingw.git;a=tree;f=nspr;hb=HEAD
http://git.annexia.org/?p=fedora-mingw.git;a=tree;f=nss;hb=HEAD

and patches named things like "nspr-configure-remove-crack.patch"
which should give you a flavour of what was involved.

On the subject of: http://wiki.winehq.org/BuildingWineGecko
Note that Fedora MinGW already supplies binutils, runtime, w32api, gcc
packages.  So any instructions about installing those can be
disregarded.  They claim to need gcc 3 (which we don't supply), but
looking at the supposed bug[1] it seems that this is issue should be
fixed in the gcc 4.4.3 (we don't yet have this, but gcc version bumps
are usually simple).

Rich.

[1] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9381

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-p2v converts physical machines to virtual machines.  Boot with a
live CD or over the network (PXE) and turn machines into Xen guests.
http://et.redhat.com/~rjones/virt-p2v