Re: Depends: libfoo:foreign ???
On 05/13/2013 09:46 AM, Wookey wrote:
+++ The Wanderer [2013-05-13 07:55 -0400]:
For the full 64+32 Wine, I don't believe this is possible - or if
it is possible, no way of doing it has yet been documented that I
know of. The official Wine documentation of how to build that
configuration involves compiling the 32-bit side on the same 64-bit
host as the 64-bit side - and, importantly, compiling it against
the already-built but not-yet-installed 64-bit build tree.
OK. I'd like to understand some more about this, as it's a similar
issue to other cross-compiler toolchains, and if we can't solve both
the same way then our design is poor. By '32+64 wine' do you mean
packages designed to be installed on an amd64 machine that run both
32bit and 64bit windows apps? Or do you mean versions of wine to run
on both i386 and amd64 machines?
The former. I don't know if there's an official term for that, but I
don't know of any other; "the full 64+32 Wine" is just what I've been
using in my own conversations as a shorthand for a longer explanation.
Theoretically it might be possible to build the 64-bit side on an
amd64 machine, make the resulting tree available to an i386
machine, let the i386 machine compile the 32-bit side against the
64-bit tree, make the resulting tree available to the amd64 machine
again, and let the amd64 machine do the final 'make install' or
equivalent process.
Just to clarify: at least for a non-package-build arrangement, the amd64
machine would have to run the 'make install' from *both* trees,
separately and in the correct order, after both builds had completed.
This isn't automated, at least not last I checked; I've had to write
wrapper scripts to automate part of it myself, for my own builds.
Hmm. Do the parts of the 64-bit tree that the 32-bit side compiles
against end up installed in a final installation (as libraries?) or
are they really just intermediate 'during build' items?
They do end up getting installed, though whether as libraries or not I
don't recall offhand.
IIRC, the end result gets wineserver from the 64-bit side, wine from the
32-bit side, and wine64 from the 64-bit side, along with supporting
files for both; I haven't examined it recently enough to remember what
libraries (aside from the numerous Wine-internal fake-DLL objects) that
may include.
If the former then the it should work to build the 64-bit tree, then
have the 32-bit build depend on a package that contains those parts
it needs to build aginst.
I think that could work, although as far as I can see it doesn't help
the normal-build scenario (i.e. not building for a Debian package, just
for a local install), which is the angle I approach this from.
Having an intermediate package containing a build tree (as opposed to
the results of installing from that build tree) seems like an
undesirable thing, though.
Still, there may not be much point doing this, and just building both
in one go on a 64-bit build machine, so the 64-part is natively
build and the 32-bit part is cross-built may make more sense. My
understanding of wine is currently too weak to say anything further.
My own understanding of Wine isn't in terribly much depth, but that is
the scenario prescribed by the official Wine documentation for building
something capable of running both 32-bit and 64-bit Windows programs,
and I at least understand why it works that way; I think I know enough
to also understand why it *has* to work that way, but I can't swear I'm
not wrong about that.
It sounds like (at least) you and Stephen Kitt and I should discuss
this (wine and mingw) further and flesh out how it should all work.
Is a debconf session a useful venue?
I'm not sure how much I'd be able to contribute to such a discussion;
I'm not actually involved with the Wine project on more than a very
peripheral level (reporting occasional bugs and trying to track them
down), I'm just a user who has use for the combined 64+32 functionality.
I'm also not familiar with what "a debconf session", in this context,
means or involves; my kneejerk interpretation was "a face-to-face
discussion session during an official Debian meetup or other
convention", but brief online searching seems to imply that that may not
be accurate.
I'd be willing to contribute what I can, however, and I'm always willing
to learn more. (It's not like I don't have enough projects already, but
this would at least be another interesting one.)
--
The Wanderer
Warning: Simply because I argue an issue does not mean I agree with any
side of it.
Every time you let somebody set a limit they start moving it.
- LiveJournal user antonia_tiger
Reply to: