On Thu, Mar 31, 2005 at 10:39:09AM +0200, Ralf Wildenhues wrote: > * Marc Singer wrote on Thu, Mar 31, 2005 at 10:10:15AM CEST: > > On Thu, Mar 31, 2005 at 08:29:23AM +0200, Ralf Wildenhues wrote: > > > Hi Marc, > > > > > > * Marc Singer wrote on Thu, Mar 31, 2005 at 12:38:53AM CEST: > > > > In the ltmain.m4 script, there is this code > > > > > > You mean ltmain.sh, right? > > > > It gets moved to .m4, yeah. That's the one. > > Almost right. :) > branch-1-5: ltmain.in -> ltmain.sh -> libtool > branch-2-0/HEAD: config/ltmain.m4sh -> config/ltmain.sh -> libtool.
Hmm. On Debian, the file is called /usr/share/libtool/ltmain.m4. > > > It'd be nice to know > > > - the exact libtool version used > > > > 1.5.6 > > Please update to at least 1.5.14. OK. > > > - a small test case to reproduce the behavior (esp. Makefile.am snippet) > > > - which of the details above trigger the behavior > > > (does the fact that you are cross-compiling do this?) > > > - a `--debug' output of the `--mode=link' step of the library > > > - `$(TOP)/scripts/config.guess` > > > - contents of autogen.sh if that does fancy stuff other than a > > > autoreconf. > > > > It turns out that the problem is kinda subtle. > > > > > I need to remark that cross-compile support in Libtool is suboptimal > > > ATM. We want to change that, but it will take quite a bit of work. > > > > I've noticed. :-) > > > > What's happening is that I'm building on a machine that has some of > > the target libraries already built. In some cases, the build of a > > library will put the /usr/lib version in the .la file of the > > cross-built package. I've not spent much time figuring out the exact > > circumstances that make that happen. > > This description is, umm, well, a description. Not precise enough to do > anything. Notice that I'm not asking for anything. > > By making sure that all of the .la files are proper, I've eliminated > > the error. Part of the trouble is that I want to build with the > > prefix as /usr so that the packages can install correctly. As yet, > > this may be something I have to relinquish. It's kindofa nuisance > > because libtool/autotools pass an -rpath $(libdir) for the linking > > phase which means that the local system's libraries are always > > available. > > We should look into using some DESTDIR-like information at link time to > override this. Noone has volunteered for auditing libtool for this yet, > the patches I've seen so far have done only patchwork. IMHO, the DESTDIR mechanism is insufficient because packages assume that $(prefix) is valid at build-time. For example the .la files. I think the build model needs to be augmented to split the runtime paths and the build-time paths. > > The one thing that would help straight away would be a way to get the > > autotools to put 'set -x' in libtool. I've been doing it by hand. > > It's been the only effect method of debugging. > > Use --debug. Set > LIBTOOLFLAGS=--debug > when using a recent Automake. Note that branch-2-0/HEAD Libtool have > slightly better `set -x' support for ksh's. Is there some place I should have looked to find this? This is what I mean about autotools being a challenge. _______________________________________________ http://lists.gnu.org/mailman/listinfo/libtool
