On Wed, 16 Jan 2013 17:55:00 +0000 Colin Watson <cjwatson@debian.org> wrote: > On Wed, Jan 16, 2013 at 03:40:52PM +0000, Neil Williams wrote: > > On Wed, 16 Jan 2013 13:50:17 +0000 > > Ian Jackson <ijackson@chiark.greenend.org.uk> wrote: > In my reply I'm going to use autoconf terminology, so host => > architecture built for, and target => only relevant when talking about > cross-tools themselves. (Not everyone likes this terminology, but it is > widespread and autoconf tends to do a better job than virtually any > other build system at supporting cross-building so I tend to end up > preferring its terms.) I remember the same convention using builD == desktop Host == handheld. Not perfect, but it may help others as it's helped me. (You can also think of Build == Big.) > > For certain host architectures: yes, definitely. Any source package > > which includes assembly (there are more than most people expect) and any > > package which then has a build dependency on a binary package > > built from the source package(s) containing assembly and so on. > > Such packages would typically fail to build natively for the > architecture in question too. Oh absolutely. > I think it's more interesting to consider > cases where, of the set of architectures on which a package can be built > natively, it can cross-build to some of those host architectures but not > others. > > However, I can't think of any such packages right now, although no doubt > anything is possible; at least, it seems to me to be rare enough not to > be worth inventing metadata for. I suspect that most such instances > will be where packages only cross-build to "similar enough" > architectures, e.g. where you happen to have a multilib toolchain > available, so amd64 to i386, or perhaps architectures with the same bit > length and/or endianness. In other words, such bugs would be a function > of the combination of build and host architectures, rather than just of > the host architecture. (I haven't run into many of these, since I > cross-build from amd64 to armhf and they're fairly different.) > > Neil, can you think of any packages that meet this stricter criterion? Not from memory, no. The list could have changed from when I last looked into it. A different - similarly strict - criterion would catch out glib2, gtk and others- introspection / marshalling code. This can cause a build failure but can also cause more difficult bugs which only show at runtime. Skipping the execution causes missing functionality, copying data from the build architecture is likely to cause other kinds of misbehaviour or crashes. I had this problem with Emdebian Crush - none of the icons would display because all of the cache data was to have been generated in the build but had to be omitted during the cross build. -- Neil Williams ============= http://www.linux.codehelp.co.uk/
Attachment:
pgpaT7qlZJQ1Z.pgp
Description: PGP signature