Re: Building and packaging Wine Gecko

[Jacek Caban]

On 12/29/09 2:07 PM, André Hentschel wrote:

Jacek Caban schrieb:
   

On 12/28/09 8:34 AM, Ove Kaaven wrote:
 

OK, I've almost got a wine-gecko package built 100% from source, but
there's a problem: the gcc version in Debian's mingw32, namely gcc
4.2.1-sjlj, apparently miscompiles the wine-gecko 1.0.0 sources, the
resulting Gecko just crashes. (The mingw32 version in oldstable, 3.4.5
something, compiles it correctly, but I can't reasonably build-depend on
it, as that version is not even in the current stable.)

(Note that this 4.2.1-sjlj might not suffer from that gcc bug 9381
mentioned on the wiki, as the testcases for it doesn't seem to crash. Or
aren't they supposed to crash?)

   

It does suffer from this bug, these tests are probably not enough to
show it.

 

I also seem to recall the gcc 4.4-based mingw32 compiler, available in
unstable, also refusing to compile those sources at all, due to numerous
problems with the headers, such as inconsistently declared calling
conventions for methods and stuff.

I'm not sure what to do about this. Any ideas about something I can do
to make it build with gcc 4.2 or 4.4?

   

The only compiler you can use for Wine Gecko 1.0.0 is GCC 3.4.5. Current
Git version uses GCC 4.4 SVN version (waiting for the first official GCC
release). All older compilers are not enough unless you'd patch them
(but that doesn't sound reasonable).


Jacek


 

Hi Jacek,
gcc 3.4.5 or 3.4.6(as mentioned in the wiki)?
   


It was a typo, it's 3.4.6 (although 3.4.5 would also work).

Thanks,
Jacek

Re: Building and packaging Wine Gecko

[Jacek Caban]

On 12/29/09 5:45 AM, Austin English wrote:

On Mon, Dec 28, 2009 at 6:53 PM, Jacek Caban  wrote:
   

On 12/29/09 1:44 AM, Ove Kaaven wrote:
 

gcc 4.4.2 is already released, and
Debian unstable is using it as the default compiler. And like I
mentioned, they even have a mingw32 cross compiler of it. Would it then
be a good idea to build wine-gecko git instead of wine-gecko 1.0.0?
Should that work?

   

That won't work, but I think it's better to spend time on working on the
next release.
 

When is the next 'release' of wine-gecko planned? E.g., when will
wine-gecko git become wine-gecko 1.1?
   


It's not yet planned.

Jacek

Re: Building and packaging Wine Gecko

[André Hentschel]

Jacek Caban schrieb:
> On 12/28/09 8:34 AM, Ove Kaaven wrote:
>> OK, I've almost got a wine-gecko package built 100% from source, but
>> there's a problem: the gcc version in Debian's mingw32, namely gcc
>> 4.2.1-sjlj, apparently miscompiles the wine-gecko 1.0.0 sources, the
>> resulting Gecko just crashes. (The mingw32 version in oldstable, 3.4.5
>> something, compiles it correctly, but I can't reasonably build-depend on
>> it, as that version is not even in the current stable.)
>>
>> (Note that this 4.2.1-sjlj might not suffer from that gcc bug 9381
>> mentioned on the wiki, as the testcases for it doesn't seem to crash. Or
>> aren't they supposed to crash?)
>>
> 
> It does suffer from this bug, these tests are probably not enough to
> show it.
> 
>> I also seem to recall the gcc 4.4-based mingw32 compiler, available in
>> unstable, also refusing to compile those sources at all, due to numerous
>> problems with the headers, such as inconsistently declared calling
>> conventions for methods and stuff.
>>
>> I'm not sure what to do about this. Any ideas about something I can do
>> to make it build with gcc 4.2 or 4.4?
>>
> 
> The only compiler you can use for Wine Gecko 1.0.0 is GCC 3.4.5. Current
> Git version uses GCC 4.4 SVN version (waiting for the first official GCC
> release). All older compilers are not enough unless you'd patch them
> (but that doesn't sound reasonable).
> 
> 
> Jacek
> 
> 
Hi Jacek,
gcc 3.4.5 or 3.4.6(as mentioned in the wiki)?

-- 

Best Regards, André Hentschel

Re: Building and packaging Wine Gecko

[Austin English]

On Mon, Dec 28, 2009 at 6:53 PM, Jacek Caban  wrote:
> On 12/29/09 1:44 AM, Ove Kaaven wrote:
>> gcc 4.4.2 is already released, and
>> Debian unstable is using it as the default compiler. And like I
>> mentioned, they even have a mingw32 cross compiler of it. Would it then
>> be a good idea to build wine-gecko git instead of wine-gecko 1.0.0?
>> Should that work?
>>
>
> That won't work, but I think it's better to spend time on working on the
> next release.

When is the next 'release' of wine-gecko planned? E.g., when will
wine-gecko git become wine-gecko 1.1?

-- 
-Austin

Re: Building and packaging Wine Gecko

[Jacek Caban]

On 12/29/09 1:44 AM, Ove Kaaven wrote:

Jacek Caban skrev:

I'm not sure what to do about this. Any ideas about something I can do
to make it build with gcc 4.2 or 4.4?
   

The only compiler you can use for Wine Gecko 1.0.0 is GCC 3.4.5. Current
Git version uses GCC 4.4 SVN version (waiting for the first official GCC
release).
 

First official GCC release of what?


First official release of GCC from 4.4 branch with the fix included.


gcc 4.4.2 is already released, and
Debian unstable is using it as the default compiler. And like I
mentioned, they even have a mingw32 cross compiler of it. Would it then
be a good idea to build wine-gecko git instead of wine-gecko 1.0.0?
Should that work?
   


That won't work, but I think it's better to spend time on working on the 
next release.


Jacek

Re: Building and packaging Wine Gecko

[Ove Kaaven]

Jacek Caban skrev:
> It does suffer from this bug, these tests are probably not enough to
> show it.

Hmm. I had hoped the debian version had patched it or something,
especially considering how often stdcall is going to be used by a win32
compiler...

>> I'm not sure what to do about this. Any ideas about something I can do
>> to make it build with gcc 4.2 or 4.4?
> 
> The only compiler you can use for Wine Gecko 1.0.0 is GCC 3.4.5. Current
> Git version uses GCC 4.4 SVN version (waiting for the first official GCC
> release).

First official GCC release of what? gcc 4.4.2 is already released, and
Debian unstable is using it as the default compiler. And like I
mentioned, they even have a mingw32 cross compiler of it. Would it then
be a good idea to build wine-gecko git instead of wine-gecko 1.0.0?
Should that work?

Re: Building and packaging Wine Gecko

[Jacek Caban]

On 12/28/09 4:51 PM, Steven Edwards wrote:

On Mon, Dec 28, 2009 at 2:34 AM, Ove Kaaven  wrote:
   

OK, I've almost got a wine-gecko package built 100% from source, but
there's a problem: the gcc version in Debian's mingw32, namely gcc
4.2.1-sjlj, apparently miscompiles the wine-gecko 1.0.0 sources, the
resulting Gecko just crashes. (The mingw32 version in oldstable, 3.4.5
something, compiles it correctly, but I can't reasonably build-depend on
it, as that version is not even in the current stable.)
 

Would it be possible to build it as a winelib application?
   


Not without a lot of work (it was discussed lately).

Jacek

Re: Building and packaging Wine Gecko

[Jacek Caban]

On 12/28/09 8:34 AM, Ove Kaaven wrote:

OK, I've almost got a wine-gecko package built 100% from source, but
there's a problem: the gcc version in Debian's mingw32, namely gcc
4.2.1-sjlj, apparently miscompiles the wine-gecko 1.0.0 sources, the
resulting Gecko just crashes. (The mingw32 version in oldstable, 3.4.5
something, compiles it correctly, but I can't reasonably build-depend on
it, as that version is not even in the current stable.)

(Note that this 4.2.1-sjlj might not suffer from that gcc bug 9381
mentioned on the wiki, as the testcases for it doesn't seem to crash. Or
aren't they supposed to crash?)
   


It does suffer from this bug, these tests are probably not enough to 
show it.



I also seem to recall the gcc 4.4-based mingw32 compiler, available in
unstable, also refusing to compile those sources at all, due to numerous
problems with the headers, such as inconsistently declared calling
conventions for methods and stuff.

I'm not sure what to do about this. Any ideas about something I can do
to make it build with gcc 4.2 or 4.4?
   


The only compiler you can use for Wine Gecko 1.0.0 is GCC 3.4.5. Current 
Git version uses GCC 4.4 SVN version (waiting for the first official GCC 
release). All older compilers are not enough unless you'd patch them 
(but that doesn't sound reasonable).



Jacek

Re: Building and packaging Wine Gecko

[Steven Edwards]

On Mon, Dec 28, 2009 at 2:34 AM, Ove Kaaven  wrote:
> OK, I've almost got a wine-gecko package built 100% from source, but
> there's a problem: the gcc version in Debian's mingw32, namely gcc
> 4.2.1-sjlj, apparently miscompiles the wine-gecko 1.0.0 sources, the
> resulting Gecko just crashes. (The mingw32 version in oldstable, 3.4.5
> something, compiles it correctly, but I can't reasonably build-depend on
> it, as that version is not even in the current stable.)

Would it be possible to build it as a winelib application?

-- 
Steven Edwards

"There is one thing stronger than all the armies in the world, and
that is an idea whose time has come." - Victor Hugo

Re: Building and packaging Wine Gecko

[Ove Kaaven]

OK, I've almost got a wine-gecko package built 100% from source, but
there's a problem: the gcc version in Debian's mingw32, namely gcc
4.2.1-sjlj, apparently miscompiles the wine-gecko 1.0.0 sources, the
resulting Gecko just crashes. (The mingw32 version in oldstable, 3.4.5
something, compiles it correctly, but I can't reasonably build-depend on
it, as that version is not even in the current stable.)

(Note that this 4.2.1-sjlj might not suffer from that gcc bug 9381
mentioned on the wiki, as the testcases for it doesn't seem to crash. Or
aren't they supposed to crash?)

I also seem to recall the gcc 4.4-based mingw32 compiler, available in
unstable, also refusing to compile those sources at all, due to numerous
problems with the headers, such as inconsistently declared calling
conventions for methods and stuff.

I'm not sure what to do about this. Any ideas about something I can do
to make it build with gcc 4.2 or 4.4?

I can also mention that I managed to build this package completely
without wintools.zip at all, by simply patching out the build of the
cross-compiled xpidl.exe. It's an xpcom developer tool and probably not
needed at runtime (and the xpidl.exe in the official wine-gecko cab
would probably have failed to run anyway, because its dll dependencies
aren't included in the cab file). A host build of xpidl is still needed
to build Gecko, but for that, only the regular Linux version of glib and
libIDL is needed, not wintools. You can disable cross-compiling
xpidl.exe by editing xpcom/typelib/xpidl/Makefile.in and kill the two
lines commented with "Sadly, the code here is too smart for the
WinCE/Symbian compiler's brain".

Re: Building and packaging Wine Gecko

[Sir Gallantmon]

On Tue, Dec 15, 2009 at 7:20 PM, Anssi Hannula  wrote:

> Apparently it is not easily possible (even if one could compile
> wine-gecko, .cab creation would be an obstacle).
>
> Therefore I've packaged the Wine provided prebuilt binary .cab as
> wine-gecko, and put it into the "non-free" repository (Cooker, and
> backports for 2010.0,2009.1,2009.0). Future builds and backports of Wine
> will contain a soft dependency ("Suggests") on wine-gecko, thus
> installing it automatically if the "non-free" repository is available.
>
> --
> Anssi Hannula
>
>
>
To create CAB files in Linux, you need the lcab[1] utility. To extract CAB
files, you need the cabextract[2] utility.

[1]: http://ohnobinki.u.ohnopublishing.net/~ohnobinki/lcab/
[2]: http://www.cabextract.org.uk/

Re: Building and packaging Wine Gecko

[Anssi Hannula]

Anssi Hannula wrote:
> Hi all!
> 
> I see that Wine has recently started to always request installation of
> Gecko, and that it is recommended to use a distribution provided package.
> 
> We do not yet provide a wine-gecko package in Mandriva, but we'd like to.
> 
> According to our policy (and the policy of e.g. Debian, Fedora)
> everything in our main repositories has to be compiled by us without
> external binaries compiled by a third party.
> 
> I noticed there are build instructions here:
> http://wiki.winehq.org/BuildingWineGecko
> 
> However, the instructions on that page ask for copying binaries directly
> provided in wine-mozilla tarball, and for modifying mingw32 headers.
> These actions are rather unacceptable for us (I guess the latter one is
> workaroundable, though).
> 
> I saw that http://wiki.winehq.org/Gecko says Gentoo and openSUSE package
> Gecko properly. I looked at the Gentoo package [1] and saw that they
> simply download the prebuilt cab, which we can't do. I took a look in
> openSUSE src.rpm [2], but found no references to Gecko, and I didn't see
> any separate wine-gecko src.rpm there. I did found wine-gecko OpenSUSE
> binary packages in Wine's SourceForge page, but no source packages or
> information on how it was built.
> 
> Is it really not possible to build Wine Gecko from the source code, on
> command line, on Linux?
> Or is it just that nobody has written any instructions on how to do that?

Apparently it is not easily possible (even if one could compile
wine-gecko, .cab creation would be an obstacle).

Therefore I've packaged the Wine provided prebuilt binary .cab as
wine-gecko, and put it into the "non-free" repository (Cooker, and
backports for 2010.0,2009.1,2009.0). Future builds and backports of Wine
will contain a soft dependency ("Suggests") on wine-gecko, thus
installing it automatically if the "non-free" repository is available.


> [1]
> http://sources.gentoo.org/viewcvs.py/gentoo-x86/app-emulation/wine/wine-1.1.34.ebuild?view=markup
> [2]
> http://download.opensuse.org/factory/repo/src-oss/suse/src/wine-1.1.28-3.4.src.rpm
> 


-- 
Anssi Hannula

Re: Building and packaging Wine Gecko

[Ove Kaaven]

Scott Ritchie skrev:
> Ove Kaaven wrote:
>> Ben Klein skrev:
>>> Have you looked at my wine-gecko-1.0.0 package at the lamaresh.net
>>> repository? It's just the pre-packaged cab file stored in
>>> /usr/share/wine/gecko.
>> That's the reason I'm not looking at it.
> 
> Would such a package be ok for the -contrib repository?

Possibly. However, I don't think it's acceptable for a package in main
(like wine) to depend on a package in contrib.

Re: Building and packaging Wine Gecko

[Scott Ritchie]

Ove Kaaven wrote:
> Ben Klein skrev:
>> Have you looked at my wine-gecko-1.0.0 package at the lamaresh.net
>> repository? It's just the pre-packaged cab file stored in
>> /usr/share/wine/gecko.
> 
> That's the reason I'm not looking at it.
> 
> 

Would such a package be ok for the -contrib repository?  There's an
equivalent in Ubuntu multiverse for the above reasons.

Thanks,
Scott Ritchie

Re: Building and packaging Wine Gecko

[Sir Gallantmon]

On Fri, Dec 11, 2009 at 9:07 PM, Ove Kaaven  wrote:

> Sir Gallantmon skrev:
> > Sorry, I think of the word "toolchain" differently I guess. I always
> > considered a toolchain to include both tools and common libraries, as
> > Fedora did. I was aware of the MinGW compiler offered in the Debian
> > package repository, but with no libraries, I considered it useless.
>
> Well, to be fair, the libraries included with mingw32 include the whole
> Win32 API, including the standard C runtime (msvcrt). What more could
> you possibly need from a "minimalist GNU for Windows" compiler for it to
> be useful...?
>
>
It almost certainly doesn't include the whole API set for Windows. It
includes the minimal Win32 API, yes, but not all the Win32 APIs. I don't
care for your bias on RPM based distros, so meh. I respect Debian's decision
not to include common libraries under cross-arching, but I personally like
the convenience that Fedora offers, especially given all the circular
dependencies some of the libraries that Fedora provides would require if
built from source.

Re: Building and packaging Wine Gecko

[Ove Kaaven]

Sir Gallantmon skrev:
> Sorry, I think of the word "toolchain" differently I guess. I always
> considered a toolchain to include both tools and common libraries, as
> Fedora did. I was aware of the MinGW compiler offered in the Debian
> package repository, but with no libraries, I considered it useless.

Well, to be fair, the libraries included with mingw32 include the whole
Win32 API, including the standard C runtime (msvcrt). What more could
you possibly need from a "minimalist GNU for Windows" compiler for it to
be useful...?

I think, though, that Debian decided not to bloat the Debian archive
with precompiled third-party libraries for mingw. They prefer to bloat
it only with packages built for the supported Debian architectures.
Cross compilers (like mingw) are often included since they need to run
on the host, but extra libraries for the non-native architecture usually
aren't, you may need to compile stuff like that yourself (or use stuff
like apt-cross/dpkg-cross if possible, but they may not apply to mingw).

Can be a bit of a pain, though, yes... but maybe, once they've finally
gotten multiarch up and running (planned for years and probably due to
occur sometime before the heat death of the universe), it'll be easier
and cleaner to deal with cross-compilation (and emulation) environments.

I think I may be able to deal with it for now though. Even the current
situation is less hassle than ever having to touch rpm... or even worse,
Fedora...

Re: Building and packaging Wine Gecko

[Anssi Hannula]

Sir Gallantmon wrote:
> On Fri, Dec 11, 2009 at 5:06 PM, Ove Kaaven  > wrote:
> 
> Ben Klein skrev:
> > Have you looked at my wine-gecko-1.0.0 package at the lamaresh.net
> 
> > repository? It's just the pre-packaged cab file stored in
> > /usr/share/wine/gecko.
> 
> That's the reason I'm not looking at it.
> 
> 
> 
> I don't think I have seen any distribution include wine-gecko. Fedora
> seems to be in the best position to finally make a wine-gecko package,
> since it now provides a MinGW toolchain. I haven't used Mandriva in
> years, so I have no idea if Mandriva includes a full blown toolchain
> like Fedora does.
> 
> If it does, you might want to look into using that toolchain to help
> make a package for wine-gecko.

Yes, it does. I don't think I have the time to figure out the Gecko
build myself without proper documentation, though :/

-- 
Anssi Hannula

Re: Building and packaging Wine Gecko

[Sir Gallantmon]

On Fri, Dec 11, 2009 at 5:37 PM, Ove Kaaven  wrote:

> Sir Gallantmon skrev:
> > I don't think I have seen any distribution include wine-gecko. Fedora
> > seems to be in the best position to finally make a wine-gecko package,
> > since it now provides a MinGW toolchain.
>
> Why does *that* put Fedora in the best position? Debian has had a MinGW
> toolchain for years, the "building wine-gecko" wiki page even mentions
> attempts to use it. Only problem with it is that it's not the newest
> version.
>
> Perhaps if you meant that Fedora also has built a whole bunch of
> libraries using mingw and packaged them as rpms, then that *might* give
> it an edge. Still won't make me ever use Fedora, though.
>

Sorry, I think of the word "toolchain" differently I guess. I always
considered a toolchain to include both tools and common libraries, as Fedora
did. I was aware of the MinGW compiler offered in the Debian package
repository, but with no libraries, I considered it useless.

Re: Building and packaging Wine Gecko

[Ove Kaaven]

Sir Gallantmon skrev:
> I don't think I have seen any distribution include wine-gecko. Fedora
> seems to be in the best position to finally make a wine-gecko package,
> since it now provides a MinGW toolchain.

Why does *that* put Fedora in the best position? Debian has had a MinGW
toolchain for years, the "building wine-gecko" wiki page even mentions
attempts to use it. Only problem with it is that it's not the newest
version.

Perhaps if you meant that Fedora also has built a whole bunch of
libraries using mingw and packaged them as rpms, then that *might* give
it an edge. Still won't make me ever use Fedora, though.

Re: Building and packaging Wine Gecko

[Sir Gallantmon]

On Fri, Dec 11, 2009 at 5:06 PM, Ove Kaaven  wrote:

> Ben Klein skrev:
> > Have you looked at my wine-gecko-1.0.0 package at the lamaresh.net
> > repository? It's just the pre-packaged cab file stored in
> > /usr/share/wine/gecko.
>
> That's the reason I'm not looking at it.
>
>
>
I don't think I have seen any distribution include wine-gecko. Fedora seems
to be in the best position to finally make a wine-gecko package, since it
now provides a MinGW toolchain. I haven't used Mandriva in years, so I have
no idea if Mandriva includes a full blown toolchain like Fedora does.

If it does, you might want to look into using that toolchain to help make a
package for wine-gecko.

Re: Building and packaging Wine Gecko

[Ove Kaaven]

Ben Klein skrev:
> Have you looked at my wine-gecko-1.0.0 package at the lamaresh.net
> repository? It's just the pre-packaged cab file stored in
> /usr/share/wine/gecko.

That's the reason I'm not looking at it.

Re: Building and packaging Wine Gecko

[Ben Klein]

2009/12/12 Ove Kaaven :
> Anssi Hannula wrote:
>>
>> However, the instructions on that page ask for copying binaries directly
>> provided in wine-mozilla tarball, and for modifying mingw32 headers.
>
> It's probably also possible to generate these at package build time by
> invoking the appropriate commands. If it's the lib*.a files, you can
> probably just build-depend on wine-dev and run i586-mingw32msvc-dlltool or
> something on the appropriate Wine .def file to get a mingw32 import library
> in .a format.
>
> I'm not sure about the wintools libs, but if they're actually needed, there
> must be a way to build them... even if it might take making official
> mingw-built packages of glib and libidl to include in the distro...
>
> Well, I've been planning to try to make a Debian package of gecko, but won't
> have time to finish it before the holidays.

Have you looked at my wine-gecko-1.0.0 package at the lamaresh.net
repository? It's just the pre-packaged cab file stored in
/usr/share/wine/gecko.

Re: Building and packaging Wine Gecko

[Ove Kaaven]

Anssi Hannula wrote:

However, the instructions on that page ask for copying binaries directly
provided in wine-mozilla tarball, and for modifying mingw32 headers.


It's probably also possible to generate these at package build time by 
invoking the appropriate commands. If it's the lib*.a files, you can 
probably just build-depend on wine-dev and run i586-mingw32msvc-dlltool 
or something on the appropriate Wine .def file to get a mingw32 import 
library in .a format.


I'm not sure about the wintools libs, but if they're actually needed, 
there must be a way to build them... even if it might take making 
official mingw-built packages of glib and libidl to include in the distro...


Well, I've been planning to try to make a Debian package of gecko, but 
won't have time to finish it before the holidays.

Re: Building and packaging Wine Gecko

[Marcus Meissner]

On Fri, Dec 11, 2009 at 10:11:59PM +0200, Anssi Hannula wrote:
> Hi all!
> 
> I see that Wine has recently started to always request installation of
> Gecko, and that it is recommended to use a distribution provided package.
> 
> We do not yet provide a wine-gecko package in Mandriva, but we'd like to.
> 
> According to our policy (and the policy of e.g. Debian, Fedora)
> everything in our main repositories has to be compiled by us without
> external binaries compiled by a third party.
> 
> I noticed there are build instructions here:
> http://wiki.winehq.org/BuildingWineGecko
> 
> However, the instructions on that page ask for copying binaries directly
> provided in wine-mozilla tarball, and for modifying mingw32 headers.
> These actions are rather unacceptable for us (I guess the latter one is
> workaroundable, though).
> 
> I saw that http://wiki.winehq.org/Gecko says Gentoo and openSUSE package
> Gecko properly. I looked at the Gentoo package [1] and saw that they
> simply download the prebuilt cab, which we can't do. I took a look in
> openSUSE src.rpm [2], but found no references to Gecko, and I didn't see
> any separate wine-gecko src.rpm there. I did found wine-gecko OpenSUSE
> binary packages in Wine's SourceForge page, but no source packages or
> information on how it was built.
> 
> Is it really not possible to build Wine Gecko from the source code, on
> command line, on Linux?
> Or is it just that nobody has written any instructions on how to do that?

For openSUSE it is currently only in the openSUSE buildservice.

For acceptance into the openSUSE distribution itself, it either needs to be:

- fully buildable from source (difficult)
- less strict licensed than (L)GPL. 

  As it is Mozilla stuff which seems dual or triple licensed, what is the 
actual license(s)
  of the wine-gecko build?

Ciao, Marcus