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?
[1] http://sources.gentoo.org/viewcvs.py/gentoo-x86/app-emulation/wine/wine-1.1.... [2] http://download.opensuse.org/factory/repo/src-oss/suse/src/wine-1.1.28-3.4.s...
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
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.
2009/12/12 Ove Kaaven ovek@arcticnet.no:
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.
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.
On Fri, Dec 11, 2009 at 5:06 PM, Ove Kaaven ovek@arcticnet.no 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.
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.
On Fri, Dec 11, 2009 at 5:37 PM, Ove Kaaven ovek@arcticnet.no 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.
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...
On Fri, Dec 11, 2009 at 9:07 PM, Ove Kaaven ovek@arcticnet.no 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.
Sir Gallantmon wrote:
On Fri, Dec 11, 2009 at 5:06 PM, Ove Kaaven <ovek@arcticnet.no mailto:ovek@arcticnet.no> wrote:
Ben Klein skrev: > Have you looked at my wine-gecko-1.0.0 package at the lamaresh.net <http://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 :/
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
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.
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.... [2] http://download.opensuse.org/factory/repo/src-oss/suse/src/wine-1.1.28-3.4.s...
On Tue, Dec 15, 2009 at 7:20 PM, Anssi Hannula anssi@mandriva.org 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/
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".
On Mon, Dec 28, 2009 at 2:34 AM, Ove Kaaven ovek@arcticnet.no 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?
On 12/28/09 4:51 PM, Steven Edwards wrote:
On Mon, Dec 28, 2009 at 2:34 AM, Ove Kaavenovek@arcticnet.no 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
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
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?
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
On Mon, Dec 28, 2009 at 6:53 PM, Jacek Caban jacek@codeweavers.com 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?
On 12/29/09 5:45 AM, Austin English wrote:
On Mon, Dec 28, 2009 at 6:53 PM, Jacek Cabanjacek@codeweavers.com 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
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)?
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
-
André Hentschel -
Anssi Hannula -
Austin English -
Ben Klein -
Jacek Caban -
Marcus Meissner -
Ove Kaaven -
Scott Ritchie -
Sir Gallantmon -
Steven Edwards