Re: Depends: libfoo:foreign ???
On 05/13/2013 11:00 AM, Wookey wrote:
+++ The Wanderer [2013-05-13 10:22 -0400]:
On 05/13/2013 09:46 AM, Wookey wrote:
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.
I was actually confusing mingw and wine when I wrote that.
That clears up a bit of confusion, then.
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.
OK. And is 32-bit wine (to be installed on amd64) an amd64 binary
that understands i386 code or is it actually i386 code? If the latter
to what degree are wine32:amd64 and wine32:i386 any different?
To the best of my ability to determine, it is the latter.
On a per-file level, I don't actually know that they are different, and
what investigation I've done seems to indicate that they may not be. On
a package-wide level, some components which get built and installed
during a standalone 32-bit build don't get built for a combined build,
because they are covered by components provided by the 64-bit build.
(The same also appears to be true in reverse.)
Do we actually (ideally perhaps) just have 2 things:
wine64:amd64 (amd64, amd64, win64)
wine32:i386 (amd64, i386, win32)
or three things:
wine64:amd64 (amd64, amd64, win64)
wine32:amd64 (amd64, amd64, win32)
wine32:i386 (amd64, i386, win32, if cross-built) (i386, i386, win32, if native-built)
where: (Build, Host, Target) means: Build is the arch built on, Host
is the arch it runs/is installed on, and target is the code/abi
'(not)-emulated'
The "three things" case seems almost accurate, except for one thing:
wine32:amd64 would be targeted to install on an amd64 host, but would be
i386 code. That may be what you intended, but I don't see it implied by
the above statement.
Perhaps this question is too simplistic once libraries are taken into
account.
I'm not sure it is; I think this may be enough to account for
everything.
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?
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.
Not if you need to rebuild both the 'library' and the tools (i.e the
whole thing), no. But if you just want to rebuild the tools then that
should work so long as the relevant 'wine32 library bits' -dev
package is installed.
I'm looking at the scenario of (potentially frequent) compilation of the
Wine development tree, rather than of a released version. Since the
32-bit and 64-bit build trees have to be built against the same source
for this to work properly, the "wine32 library bits" package wouldn't
help.
multiarch layouts won't help for upstream builds unless they adopt
support for it (which would be good). I've only been thinking about
the packaged version. upstream stuff is a different matter.
Acknowledged. For packaging purposes, this does seem like a reasonable
approach, modulo the questionability of a separate build-tree-only
package.
(It seems to me that coinstallable multiarch -dev packages would allow
this to work for Wine with the existing documented approach, with no
upstream changes; it's certainly worked fine with ia32-libs-dev so far.
But I agree that this is a separate question.)
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.
If what is being built is all amd64 code, then clearly it makes sense
to build it all in one go, on one machine. If part of what is being
built is i386 code, depending on :i386 libs then it may make sense to
do part of that on i386 build machines, or it may make more sense to
cross-build it on amd64.
Part of what is being built is i386 code, and so far, the official
upstream documentation recommends the latter. The former may be
possible, but no means of doing it has been documented so far that I
know of.
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",
That's exactly it, and I had Debconf Switzerland in mind as it's
coming up fairly soon, but that may well not be convenient for you.
Given that I'm in America, don't have much to spare for travel expenses,
and don't even presently have a passport, that might be a fair
description. I would be theoretically interested in attending, but for
at least the next year or two, practicality is likely to be another
matter.
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.)
OK. I guess real progress might depend on the maintainer(s) being
interested in this.
Seems likely.
I've considered trying to get involved with the Debian packaging of
Wine, but with the number of other projects I have backlogged, it hasn't
seemed like a good idea. If I can contribute to at least theoretical
discussion, however, I wouldn't be averse to doing that.
--
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: