Re: Depends: libfoo:foreign ???
+++ The Wanderer [2013-05-13 10:22 -0400]:
> 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.
I was actually confusing mingw and wine when I wrote that.
> 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?
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'
Perhaps this question is too simplistic once libraries are taken into
account.
> >>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.
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.
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.
> 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.
Yes, it only makes sense if this part is essentially a library-dev
package type thing which has some logical existence in it's own right,
as something to build-dep on.
> >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.
> >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.
> 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.
Wookey
--
Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM
http://wookware.org/
Reply to: