| Summary: | app-emulation/wine: shared 64bit suppport win64/wine64 | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Michael Weber (RETIRED) <xmw> |
| Component: | Current packages | Assignee: | Wine Maintainers <wine> |
| Status: | RESOLVED FIXED | ||
| Severity: | enhancement | CC: | fling, maltee, nbowler, oakad |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | AMD64 | ||
| OS: | Linux | ||
| URL: | http://wiki.jswindle.com/index.php/General_Wine_Information#64Wine_and_Wine_on_64 | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: |
wine64 in addition to wine (32bit)
copy from portage tree wine-1.1.42.ebuild another non-functioning ebuild bzip2'ed build.log (2.5M) wine-1.1.43 parallel build.log wine-1.1.43 non-parallel build.log wine-1.2.ebuild patch with wow64 working wine-1.2.ebuild |
||
|
Description
Michael Weber (RETIRED)
2009-12-12 13:26:54 UTC
Created attachment 212794 [details]
wine64 in addition to wine (32bit)
-wine's configure does not handle --program-suffix. I had to install almost everything to /opt/wine64.
-the fonts and wine.inf in /usr/share/wine could not be moved and would conflict with app-emulation/wine -> runtime dependency to app-emulation/wine[-win64].
-wine64 does work, but I'm not sure which winedbg/... get's called by wine64.
Created attachment 212795 [details]
copy from portage tree
copy of /usr/portage/app-emulation/wine/files/wine-1.1.15-winegcc.patch
I don't know where to locate package.use.mask inside a layman-managed overlay. I've added app-emulation/wine64 -dbus -gnutls -gphoto2 -gsm -hal -jpeg -ldap -mp3 -nas -openal -scanner to /etc/portage/package.use. see http://svn.xmw.de/gentoo-overlay/ really needs a solution that doesnt involve duplicating everything (In reply to comment #4) > really needs a solution that doesnt involve duplicating everything ack, in upstream. But currently the only common files were unduplicated in /usr/share/wine and gentoo should provide both 'versions' at the same time. i'm talking about the ebuild. i'm not going to merge a new "package" which is a duplicate of an existing package but a new name. if you actually feel like doing the work here (honestly, i'm not), you can add a "win32" USE flag to the current ebuild and that will take care of building the right versions of wine: USE="-win32 -win64" - install wine32 USE=" win32 -win64" - install wine32 USE="-win32 win64" - install wine64 USE=" win32 win64" - install wine32 and wine64 h(In reply to comment #6) > i'm talking about the ebuild. i'm not going to merge a new "package" which is > a duplicate of an existing package but a new name. I can comprehend your feeling and your suggested use flag constellation. But the request for the additional win64 stuff would trigger a recompilation of the (already installed) win32 stuff. Ok, it's the era of ccache, multicore and distcc, but the people from sunrise (were I tried to place some of my past efforts) bashed me continuing for doing recompilations. > if you actually feel like doing the work here (honestly, i'm not), you can add > a "win32" USE flag to the current ebuild and that will take care of building > the right versions of wine: > USE="-win32 -win64" - install wine32 > USE=" win32 -win64" - install wine32 > USE="-win32 win64" - install wine64 > USE=" win32 win64" - install wine32 and wine64 If you think that's the right way, I can do so. But it would relocate the replication of the ebuild to loops inside of src_prepare, src_compile and src_install because of the --enable-win64 parameter of configure. It's a divertion between wine32 and wine64, not an option for additional wine64. The validity of the whole effort (produced as one flagged or two ebuilds) has to be proven in addition. the libs would be installed to /usr/lib{32,64} but he bins end up in /usr/bin with no shipped --program-suffix option. This becomes a problem inside the kernel32.so which calls winedbg by name in case of a crash - which should be the right one, I assume. Michael you're talking a one-off cost which is largely irrelevant considering how often new versions of wine are released. as for the sunrise stance, i dont care. there are plenty of ebuilds in the tree which can be used as an example (like ncurses). the econf/etc... steps are given their own function and called as needed based on USE flags with specific configure flags. patching & pushing upstream a program-suffix solution should be fine *** Bug 299987 has been marked as a duplicate of this bug. *** The winehq homepage says "Support for shared 32/64-bit setups" in the release notes of wine 1.1.42: http://www.winehq.org/announce/1.1.42 This should be solving this bug. 1.1.42 got intro tree, should be fixed now, see #314447. wine itself doesnt "just work". the ebuild still needs modification. Created attachment 228487 [details] wine-1.1.42.ebuild here is a stab at things, but it doesnt really work and i dont have time to get it working see http://wiki.winehq.org/Wine64ForPackagers http://wiki.winehq.org/Wine64 describes something like this, look out for the --with-wine64 mkdir "${S}"/wine64 cd "${S}"/wine64 ../configure --enable-win64 CC=$(tc-getCC) make > make.log 2>&1 mkdir "${S}"/wine32 cd "${S}"/wine32 ../configure --with-wine64=../wine64 make > make.log 2>&1 this two configure;make runs call out for an non-conventional src_compile with the above code and ignoring the src_configure. Or maybe the first configure in src_configure for the checks and the rest in src_compile. I'll check it out. Created attachment 228623 [details]
another non-functioning ebuild
i should have looked better to see SpanKY's ebuild.
Mine doesn't drop the multilib_toolchain_setup x86 for -win64 on x86.
build.log follows
Created attachment 228625 [details] bzip2'ed build.log (2.5M) i've tried to multilib_toolchain_setup x86 during the compilation in wine32, but then a link invocations fails with elf64_x86_64 and elf32_x86 cannot be linked together. I had to set MAKEOPTS="-j1" otherwise i got "rm fonts: fonts cannot be removed, it's a directory", twice. I think the "Could not open importlib stdole2.tlb" error is described at http://wiki.winehq.org/JohnKlehm Michael (In reply to comment #13) > Created an attachment (id=228487) [details] > wine-1.1.42.ebuild Just checked, same result, "Cannot remove fonts dir" in parallel mode, and "error: Could not open importlib stdole2.tlb." in non-parallel mode. Created attachment 230643 [details]
wine-1.1.43 parallel build.log
Just checked SpanKY's ebuild against 1.1.43 version,
rm: cannot remove `fonts': Is a directory
make: *** [fonts] Error 1
rm: cannot remove `server': Is a directory
make: *** [server] Error 1
This build system could use a deeper look.
Created attachment 230649 [details]
wine-1.1.43 non-parallel build.log
Bug 296608 depends on: 328687 The Wine team is proud to announce that the stable release Wine 1.2 is now available. This release represents two years of development effort and over 23,000 changes. The main highlights are the support for 64-bit applications, and the new graphics based on the Tango standard. no, it does not Created attachment 239251 [details, diff] wine-1.2.ebuild patch with wow64 (In reply to comment #21) > no, it does not > Actually, yes, it does. I made an ebuild with the directions of comment #14 and it works nicely so far. With a "wow64" USE flag, it installs a wine and wine64: wine64 accepts both 32 and 64 apps, and while wine doesn't, it falls back gracefully to wine64 after a small error "Trying to load PE image for unsupported architecture (AMD-64)" I'm not that experienced with making ebuilds, so feel free to correct anything you find inappropriate. Enjoy! =D Ok, now I see that wine64 also fails with 32bit and falls back to wine... Sorry about the mix up, but still works! =P Humm, looks like it still won't play nice with 32bit installers of 64bit apps. I tried installing the unofficial firefox and it borked by the end of the install. Apparently it only tests if it's 32 or 64 at the beginning, then fixes that value through the execution, and when the 32bit installer tries to call the 64bit app it fails... It's probably a bug upstream though... =/ (In reply to comment #22) > (In reply to comment #21) > > no, it does not > Actually, yes, it does. I didn't see the "depends on: 328687" in comment #21 and misinterpreted your answer. You're absolutely right, it does not depend on the version bump. Sorry about that... Created attachment 239555 [details] working wine-1.2.ebuild (In reply to comment #13) > Created an attachment (id=228487) [details] > wine-1.1.42.ebuild > > here is a stab at things, but it doesnt really work and i dont have time to get > it working > > see http://wiki.winehq.org/Wine64ForPackagers > Since I had some time, I looked at your ebuild (which is much better written than mine) and made it work by adding an ABI=x86 before the 32bit do_configure() and returning to the default after. Thank you for your pacience, I'll stop bothering now... =P thanks, ive merged that into wine-9999. if things go well, i'll merge it into the next released version too. http://sources.gentoo.org/app-emulation/wine/wine-9999.ebuild?r1=1.54&r2=1.55 (In reply to comment #27) > thanks, ive merged that into wine-9999. if things go well, i'll merge it into > the next released version too. I think this should be supported in 1.2, too, because it's the stable version and many people might want to run it for the next months. *** Bug 337335 has been marked as a duplicate of this bug. *** |