+++ Kurt Roeckx [2012-07-23 16:31 +0200]: > On Mon, Jul 23, 2012 at 02:46:51PM +0100, Wookey wrote: > > On Thu, 2012-07-19 at 08:45 +0200, Kurt Roeckx wrote: > > > I think that's just wrong. The /usr/bin/libtool file is generated > > > for the current architecture and doesn't support cross-building. > > > It's also the only reason this is an arch any package and not an > > > arch all pacakge. > > > > erm. libtool supports cross-building as part of the GNU autotools > > suite. I must admit to being vague about exactly how it all works, but > > my understanding is that you want the build arch version of libtool > > installed so that the build machine can run it at build-time. > > > > /usr/bin/libtool is indeed generated for the current i.e 'build' > > architecture. I suspect Kurt is confused about what M-A: foreign means > > - it means a build-dep that can be satisfied by a foreign > > architecture (normally the one you are building stuff on). i.e when > > building libxaw for armel on an amd64 machine the 'libtool' Build-dep > > is satisfied by libtool:amd64, which is the version that can run on > > this machine. That is smart enough to to know to look up lib paths for > > armel, not amd64.
[apologies for impugning your understanding - it seems it is me that is insufficiently informed] > The reason this works in most cases is because the B-D is used > to provide the files in /usr/share/aclocal/ and > /usr/bin/libtoolize. > > If you use it for /usr/bin/libtool it won't work. Hmm. Even though libtool is a shell-script. I see it does indeed contain an awful lot of refernces to both build and host being x86_64-linux-gnu on this amd64 system. So is the correct way to use libtool when crossbuilding via a <triplet>-libtool configured as a cross-libtool with something like this?: $ tar xzf libtool-2.4.2.tar.gz $ cd libtool-2.4.2 $ ./configure --prefix=/usr --host=target --program-prefix=target- Thing is, there are lots of things broken about cross-building, but in practice I've never noticed the need for a cross-libtool like this. Do you have any examples of usage like this so I can see what's actually going on and work out what we should be doing about it? Of your 4 options, I'm not sure what is best either. Of the 730 build-deps on libtool, how many want arch-independent libtool bits and how many want build-arch bits and how many want host arch bits? I have no idea. Is there a good way to find out? My current understanding is that they usually want libtool:build (which is what we get by marking it M-A: foreign and not changing anything else, but that doesn't allow for exceptions). Anything that uses /usr/bin/libtool:host during a cross-build will fail anyway when it can't run, so do we actually care about that case? Isn't it just a cross-build bug? Seems to me that either a <triplet>-libtool is needed or the usage should simply be avoided. I'm happy with 2 or 4. I don't fancy changeing most of 730 r-build-deps much. I wish M-A: allowed had the opposite sematics (so we only had to annotate host-arch usages, not build-arch usages in build-deps). I think this is much more common for things where M-A: allowed is useful. But sadly we can't change it now, and I assume there is a good reason for it being this way round. I always find libtool tiresome, as nearly all of what it does is just needless complication so far as I can see - our toolchains know perfectly well where libs can be found, and asking them is a lot simpler to grok and more reliable than asking libtool. No doubt there are situations where it helps, but I've yet to find one I care about :-) Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/ -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
