Re: Depends: libfoo:foreign ???
+++ 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/
Reply to: