+++ The Wanderer [2013-05-13 07:55 -0400]: > On 05/09/2013 11:59 AM, Wookey wrote: > > >+++ Goswin von Brederlow [2013-05-09 11:39 +0200]: > > >>I would say that a foreign dependency on a library is never right. > > > >That's too strong. It can make sense for cross-tools, or maybe > >emulators, which genuinely need a foreign-arch library to operate. > >But I'm not aware of other sensible usages. > > If I'm correctly understanding what's being described here, I would > think that the full-functionality 64+32 Wine would probably be another > exception (unless it falls under "emulators", in which case "another" > doesn't apply); the 64-bit side is built against and depends on 64-bit > libraries, and the 32-bit side is built against and depends on both > 32-bit libraries and the already-built 64-bit side, and both sides are > needed for an install capable of handling both 32-bit and 64-bit Windows > programs. > > I don't see any practical way to let a package providing the > full-functionality 64+32 Wine work without depending on both the 64-bit > (native) and the 32-bit (foreign) libraries.
OK. If that's how it works, then I agree - this is another sensible use-case. Thanks for the explanation. > >>If the source compiles binaries for the foreign arch then the > >>package should be build on the foreign arch directly. Period. > > > >Apart from the above exceptions, I agree. > > 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? > 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. 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. 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. > I wouldn't > expect that to actually work, though, given that it looks like the Wine > "tools" built on the 64-bit side may get run during the 32-bit side of > the build - and even if it does work, that seems like far more trouble > than should be justifiable for what is otherwise a straightforwardly > scriptable build process. There are various aspects to this, such as making it buildable on our autobuilders, trying not to diverge too much from upstream/getting them to understand how multiarch is useful, and incorporating that into the build system, future expansion of wine to other architectures (arm/arm64). I'd hope that using multiarch makes these things simpler, not more complicated. Arranging to build things on the arch they are inteded to be run on seems a sensible initial stance, but I'm not going to be religious about it if it turns out to be a daft idea. > (This is the main use case I have for multi-arch -dev packages; without > them, the only way I can think of to potentially accomplish a full 64+32 > Wine build which I would expect to result in full functionality is to > identify all -dev packages needed for the desired Wine library support, > then pause in between build stages to manually swap which architecture > of each of those -dev packages is installed - and swap back afterwards > for normal compilation of other things.) Right. You should be able to install any needed foo-dev:<host-arch> packages on your build system and either build natively against them if you are building on the correct arch, or cross-build against them if on a foreign arch. That's how it should work. The neat (and radical by past standards) bit being that the the -dev:<host-arch> packages are the same packages (in the same paths) for both cases. 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? Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130513134602.gu2...@stoneboat.aleph1.co.uk
