On Tue, 14 May 2013 17:37:59 +0100, Wookey <woo...@wookware.org> wrote: > +++ Stephen Kitt [2013-05-13 19:26 +0200]: > > Yes, but that's not the problem. Take the premise that the target > > directory structure is as described above, so most library development > > packages ship as many headers as possible in /usr/include. For now we'll > > assume all mingw-w64-...-dev headers are in /usr/include/...-w64-mingw32; > > but to use mingw-targeted libraries other than mingw-w64-...-dev (libgtk > > for example), the mingw toolchain needs to look in /usr/include as well. > > > > This is all fine as long as libc6-dev is not installed (say perhaps with > > sbuild and cross-build-essential). But in a typical work environment, > > libc6-dev will be installed, and because we'll always be cross-compiling > > on the buildds, packages which need to build stuff for the host to run > > during the build (wine-gecko does this) need build-essential too, so > > libc6-dev headers end up in /usr/include and are picked up by the mingw > > toolchain. > > Thank you for explaining this. I now understand your issue. It is > helpful to have an example of why a full-split might have advantages > over an 'only arch-dependent' split. Or at least that we need to be > careful about what the definition of 'arch-dependent' is, if we want > to include windows ABIs, or uclibc ABIs (I think those two cases may > well amount to the same problem). Can anyone from BSD camp tell us > whether having glibc-dev headers installed in a common dir would break > cross-building for them too? > > Simon has expanded on this helpfully already: 'glibc is somewhat > special as part of the ABI' (remembering that multiarch maps to ABIs).
Right, and thank you Simon for explaining things more clearly than I could! > It's good to know about this before the design is set in stone, so > this conversation is timely. What I'm not sure about is whether the > multiarch-cross design is seriously broken or if it's just a matter of > packaging libc-dev correctly to allow for non-glibc platforms. > > Multiarch has thus far largely been thought of in terms of platforms > you can also install Debian to as well as build for. But > multiarch-cross ought to be a good fit for crossing to other platforms > (within reason) too. So we should certainly consider whether we can > sensibly accomodate that or not. > > I'm not quite sure how best to decide that. Some people need to try > some stuff and report back, I suspect. Quite likely! I should probably just rebuild the mingw toolchain using multiarch paths and see what breaks ;-). > Would simply moving all the libc headers to /usr/include/$multiarch > fix mingw builds? How many other libraries are similarly affected? I think as far as libc is concerned, moving the headers away should be enough. Off the top of my head the only packages I can see causing trouble is linux-libc-dev, and kernel-specific packages like it (so basically anything which is linux-any rather than any, or kfreebsd-specific or hurd-specific, with files in /usr/include). In a perfect world nothing else should: if a header file is in /usr/include (or a well-known subdirectory), the corresponding library should be available on all Debian architectures and partial architectures. Certainly from the point of view of Debian packages that should be enough: it's the usual problem of packaging reverse-dependencies, albeit slightly extended (since a build-dependency for a host-based portion of a cross-build may confuse the target-specific portions of the build). For end-users it's not quite so simple, and if we want Debian to be a nice platform for cross-building we may need to be stricter (and I realise that's a big if anyway, and cross-builders should know what they're doing well enough to cope with the deficiencies here). The easy solution to deal with partial architectures' limitations is to move everything out of /usr/include, the hard solution is to make sure as many libraries as possible are available for the partial architectures... It all boils down to what the baseline is for all Debian architectures, and hence what is common across all architectures. As Simon points out stuff which uses pkg-config should be safe enough. Likewise configure scripts which check the library as well as the header files. Regards, Stephen
signature.asc
Description: PGP signature
